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Preface 


The  purpose  of  this  thesis  was  to  demonstrate  the 
applicability  of  expert  systems  co  the  domain  of  satellite  command 
and  control,  specifically,  NAVSTAR  anomaly  resolution.  A 
prototype  expert  system  was  constructed  which  successfully  handles 
many  Attitude,  Velocity  and  Control  Subsystem  and  Electrical  Fower 
Subsystem  anomalies.  The  project  was  sponsored  by  the  USAF  Space 
Command's  Second  Space  Wing  (2  SW)  with  extensive  support  by  the 
Second  Satellite  Control  Squadron  (2  SCS). 

The  topic  was  suggested  by  Capt  Cecil  Longino  o£  the  2  SW  who 
also  helped  make  TDY  funds  available.  Others  instrumental  in  the 
project's  success  were  Maj  Mike  Shaw,  Capt  Dale  Wilson,  and, 
especially,  Lt  Gil  Villanueva,  all  of  the  2  SCS.  Closer  to  home, 
my  classmate,  Capt  Ed  Crawford,  was  a  constant  source  of 
encouragement  and  friendship.  Capt  Bob  Hammell  and  Lt  Steve 
Wagner  helped  by  sharing  the  "secrets"  of  Guru.  Of  course,  my 
advisor  Lt  Col  Greg  Parnell  must  receive  credit  and  thanks  for  his 
professional  guidance  and  many  insights.  If  I  learned  from  this 
research  effort,  it  was  because  he  let  me  make  the  tough 
decisions . 


I  also  wish  to  thank  my  beautiful  wife,  Capt  Lisa  Rampino, 
for  enduring  our  physical  separation  during  our  first  15  months  of 
marriage  and  for  the  many  long  distance  counseling  sessions. 
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Abstract 

The  Operational  NAVSTAR  Global  Positioning  System  (GPS) 
satellite  constellation  is  operated  entirely  by  U.S.  Air  Foice 
military  personnel.  The  ’’Blue  Suit"  satellite  engineers  must  meet 
the  challenge  posed  by  on-orbit  anomalies  without  the  extensive 
contractor  technical  support  available  to  most  satellite  systems 
in  the  past.  These  engineers  are  generally  less  experienced  than 
their  contemporaries  in  other  systems,  but,  most  importantly,  they 
will  take  their  expertise  with  them  when  they  leave  for  a  new 
assignment . 

The  objective  of  this  research  was  to  demonstrate  the  ability 
of  expert  systems  to  maintain  corporate  knowledge,  aid 
inexperienced  satellite  engineers,  and  take  advantage  of  the 
"economies  of  scale"  nnssible  by  developing  the  system  for  a  many 
satellite  constellation. 

The  NAVSTAR  Anomaly  Resolution  Expert  System  (NAVARES)  is  a 
rule-based  expert  system  prototype  that  successfully  handles  many 
anomalies  in  the  Attitude,  Velocity  and  Control  Subsystem  (AVCS) 
and  the  Electrical  Power  Subsystem  (EPS).  Anomaly  resolution 
procedures  and  heuristics  are  represented  in  the  knowledge  base 
with  rules  and  procedural  code.  The  user  interacts  with  NAVARES 
by  answering  system  queries  about  the  status  of  the  satellite. 
NAVARES  uses  its  expert  knowledge  to  diagnose  the  satellite 
anomaly  and  recommend  a  remedy.  The  output  consists  of  the 
diagnosis,  remedy,  and  titles  of  relevant  past  anomaly  reports. 

vi  i 


NAVARES:  A  PROTOTYPE  EXPERT  SYSTEM 


FOR  NAVSTAR  ANOMALY  RESOLUTION 


I .  I ntr oduction 


Background 

Artificial  Intelligence  (AI)  means  different  things  to 
different  people.  In  general,  AI  can  be  defined  as  "the  study  of 
how  to  r  computers  do  things,  at  which,  at  the  moment,-  people 
are  better''  (24:1).  This  definition  encompasses  many  active  and 
potentially  fruitful  research  areas  such  as  machine  vision, 
robotics,  natural  language  understanding,  and  knowledge  based  or 
expert  systems.  The  area  which  appears  to  have  the  greatest 
potential  fo*.  bearing  fruit  in  the  near  term,  particularly  for 
satellite  command  and  control  applications,  is  expert  systems 
(26:29). 

Sxpert  systems  emerged  within  the  last  decade.  In  the  early 
days  of  AI  research,  scientists  concentrated  on  trying  to 
simulate  the  human  thought  process  by  finding  general  methods  for 
solving  broad  classes  of  problems  (24:2)  The  results  were  less 
than  satisfying  for  "real  world"  applications.  But,  in  the  early 
seventies,  researchers  began  concentrating  on  other  ways  to  make 
computers  "intelligent"  (28:4).  They  tried  to  find  ways  to 
represent  problems  that  would  make  them  easier  co  solve,  and  to 
find  clever  ways  to  search  for  a  solution  so  that  computation  time 
and  the  necessary  memory  capacity  could  be  minimized.  In  the  late 
seventies  came  the  realization  that  the  power  of  a  program  comes 


will  not  be  completely  reacted.  As  the  rate  of  reaction  is 
slowed  the  maximum  thickness  of  carbon  must  also  be  reduced 
since  there  is  a  much  smaller  temperature  excursion  to  aid 
reaction.  While  relatively  large  carbon  particles  (>100  pm)  can 
be  fully  reacted  with  large  exotherms  this  is  to  be  avoided 
since  it  generally  coarsens  both  the  resulting  silicon  carbide 
ami  cause"'  silicon  lakes  due  to  solution  and  reprecipitation  or 
may  cause  cracking. 

it  is  also  necessary  to  decrease  the  maximum  particle 
size  as  the  skeleton  density  is  raised  particularly  in  the  range 
where  the  residual  silicon  is  below  10  Vol%.  In  this  case  the 
flow  is  slower  due  to  the  lower  volume  of  delivery  channels  and 
each  particle  is  further  from  its  reactant  supply.  Previous  ef¬ 
forts'1  showed  that  the  maximum  size  should  be  below  10  pm  for 
complete  reaction  with  a  skeleton  density  in  the  range  of  .8  to 
.85  ym/cm^.  It  has  been  found  that  at  higher  densities  that  the 
maximum  size  needs  to  be  further  reduced,  probably  to  less  than 

2  pm . 

In  the  current  period  several  dozen  different  batches 
have  been  produced  aiming  at  a  pore/particle  size  less  than  1  pm 
and  the  range  ~l-3  pm.  Several  of  these  have  been  made  in  two 
density  levels  so  that  processing  and  properties  can  be  evalu¬ 
ated  as  a  function  of  residual  silicon  content. 

The  carbon  skeleton  can  be  shaped  in  several  ways.  It 
may  be  cast  or  machined  in  the  polymerized  state  or  machined 
after  carbonization.  Each  has  advantages  in  certain  cases. 
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from  the  knowledge  it  possesses,  not  just  the  formalisms  and 
inference  schemes  it  uses.  Thus  the  term  "expert  system"  has  come 
to  describe  a  computer  program  that  has  a  great  deal  of  specific 
knowledge  about  a  problem  area  that  is  generally  very  narrow  and 
well  bounded. 

Expert  systems  may  have  applications  In  the  arts  of  satellite 
command  and  control.  Maj.  Robert  J.  Kruchten,  program  manager  of 
the  U.F.  Air  Force's  Satellite  Autonomy  ProgLam,  has  outlined  some 
problems  in  satellite  command  and  control  that  expert  systems  may 
be  able  to  solve.  (14:1)  The  problem  areas  can  be  categorized  as 
dealing  with  people  or  time. 

The  people  problems  stem  from  several  sources.  It  takes 
years  to  train  an  individual  who  is  expert  in  resolving  anomalies 
aboard  a  given  satellite.  As  satellites  become  longer  and  longer 
lived,  it  becomes  more  difficult  to  xetain  these  experts  over  the 
lifetime  of  the  satellite.  The  increasing  number  of  satellites  on 
orbit  today  and  predicted  to  be  on  orbit  in  the  future  compounds 
this  dilemma.  If  the  plans  tor  the  Strategic  Defense  Initiative 
are  implemented,  there  could  easily  be  100  satellites  added  to 
those  already  on  orbit  (6:38),  And  100  satellites  is  a 
conservative  estimate.  Lastly,  the  USAF  is  transferring  command 
and  control  of  many  satellite  systems  to  the  Air  Force  Space 
Command.  The  Air  Force  Space  Command  operators  are  military 
members  who  will  rotate  positions  frequently,  taking  their 
expertise  with  them  when  they  leave  for  new  assignments. 


The  time  problem  sterns  from  the  fact  that  some  satellite 
failures  may  take  weeks  to  resolve.  A  two-week  wait  might  be 
acceptable  for  resolving  an  anomaly  aboard  a  scientific  research 
satellite,  but  systems  that  play  a  vital  role  in  our  nation's 
security  must  be  returned  to  normal  operations  immediately.  As 
space  systems  play  a  larger  role  in  defense,  as  with  £DI,  response 
times  must  be  shortened. 

This  research  topic  was  suggested  by  Capt  Cecil  Lonqlno  of 
the  Air  Force  Space  Command's  Second  Space  Wing  (17). 

Specifically,  he  requested  that  research  be  conducted  to  determine 
the  possible  applicaticns  of  AI  to  two  areas:  real-time  anomaly 
resolution  and  automated  commanding  for  a  multiple  satellite 
constellation , 
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The  goal  of  this  thesis  is  to  demonstrate  the  applicability 
of  AI  to  satellite  command  and  control  by  developing  a  prototype 
etpert  system.  The  domain  for  the  prototype  is  restricted  to 
anomaly  resolution  for  a  subset  of  the  possible  anomalous 
conditions  aboard  the  NAVSTAR  Global  Positioning  System  (GPS) 
satellites . 

The  GPS'  constellation  is  a  very  good  target  for  thie 
research  since  there  are  many  nearly  identical  satellites  on 
orbit.  Also,  command  and  control  of  GPS,  including  anomaly 
resolution  is  performed  exclusively  b>  Air  Force  personnel  of  the 
Second  Satellite  Centre!  Squadron  (2  SCS).  Frequent  assignment 
changes  fc~  military  personnel  mean  a  constant  loss  of  expertise 
and  an  expert  system  can  contribute  to  maintaining  corporate 
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knowledge.  However,  the  NAVSTAR  Anomaly  Resolution  Expert  System 
(NAVARES)  is  not  meant  to  replace  satellite  engineers,  but  to 
augment  their  knowledge  and  expertise. 

Scope 

A  GPS  satellite  consists  of  nine  subsystems.  Due  to  the  time 
constraint  imposed  on  this  research  effort  only  two  of  these 
subsystems  are  diagnosed  by  the  thesis  prototype.  The  Attitude, 
Velocity  and  Control  Subsystem  and  the  Electrical  Power  Subsystem 
were  chosen  at  the  suggestion  of  the  2  SCS  Satellite  Engineering 
Branch.  In  addition,  NAVARES  does  not  interface  with  other 
equipment  or  software  available  at  the  2  SCS. 


Assumptions 

This  research  effort  was  conducted  with  three  assumptions  in 
mind.  First,  the  users  of  the  system  will  be  GPS  satellite 
engineers  who  have  at  least  a  basic  understanding  of  the 
satellites'  design  and  functions.  Second,  the  expert  system  will 
not  replace  human  judgement.  There  will  always  be  a  "man  in  the 
loop."  Third,  the  prototype  will  prove  useful  to  the  2  SCS 
satellite  engineers  if  it  is  expanded  to  include  the  remaining 
subsystems  and  maintained  to  include  the  latest  knowledge  of 
satellite  anomalies. 
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Support  Requirements 

Access  to  the  experts  at  the  2  SCS  was  essential.  A  two-week 
visit  was  made  to  Falcon  AFS,  CO  to  study  the  problem  domain  and 
gather  pertinent  information.  Time  was  spent  in  classroom 
sessions/  the  Master  Control  Station  (MCS)  which  is  the 
operational  center  of  the  GPS  system/  and  interviewing  satellite 
engineers  who  perform  anomaly  resolution.  In  addition/  many 
telephone  interviews  and  correspondence  with  the  satellite 
engineers  was  necessary. 

The  equipment  used  to  construct  the  prototype  consisted  of  an 
IBM  Personal  Computer  (PC)  compatible  machine,  the  Zenith  248  with 
a  20M  byte  hard  disk,  and  a  PC  based  expert  system  building  tool. 
Guru  ( 20 ) . 

Overview 

This  chapter  has  provided  a  brief  introduction  and 
background.  Chapter  II  describes  the  methodology  used  to  guide 
this  research  effort.  Chapter  III  is  a  survey  of  the  current 
literature  relevant  to  this  work.  Chapter  IV  describes  the 
knowledge  engineering  phase,  and  presents  background  information 
on  GPS  operations  and  an  explanation  of  the  GPS  anomaly  resolution 
process.  Chapter  V  outlines  the  system  requirements.  Chapter  VI 
reviews  the  system  design  and  implementation  process,  including 
tool  selection.  Chapter  VII  presents  an  evaluation  of  the 
implemented  system.  Finally,  Chapter  VIII  outlines  research 
conclusions  and  recommendations  for  future  efforts. 
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I I .  Methodology 


Introduction 

This  thesis  research  was  conducted  using  the  systems  approach 
to  problem  solving.  The  project  was  divided  into  subtasks  to  be 
accomplished  in  a  step-by-step  fashion.  This  chapter  presents 
each  step  of  the  process  in  detail. 

Understanding  the  Problem 

A  literature  review  was  conducted  to  determine  the  progress 
made  in  the  area  of  expert  systems  for  satellite  anomaly 
resolution.  Chapter  III  presents  the  results  of  this  review.  A 
number  of  prototype  systems  have  been  developed  and  are  discussed, 
but  no  operational  systems  were  found.  The  review  also  addressed 
the  current  theoretical  approaches  to  the  problem  domain. 

Satellite  Program  Selection 

The  NAVSTAR  GPS  satellite  constellation  was  selected  as  the 
appropriate  satellite  program  to  study  for  three  reasons.  First, 
because  the  GPS  constellation  consists  of  many  nearly  identical 
satellites  on  orbit  it  would  be  possible  to  diagnose  problems  on 
all  the  satellites  in  the  constellation  with  the  same  system,  thus 
achieving  "economies  of  scale."  Also,  the  satellite  engineers  who 
must  trouble-shoot  problems  will  face  a  great  work  load  when  the 
final  constellation  of  21  satellites  is  deployed.  An  expert 
system  has  the  potential  to  lighten  the  load  by  augmenting  the 

l 

satellite  engineers'  expertise.  Second,  and  perhaps  most 
Important,  the  GPS  system  is  run  exclusively  by  U.S.  Air  Force 
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personnel.  Frequent  assignment  changes  for  military  personnel 
mean  a  loss  of  expertise  which  may  be  offset  by  the  permanence  of 
an  expert  system.  Third,  the  fact  that  the  GPS  system  is  largely 
unclassified  meant  easy  access  for  the  knowledge  engineer. 

Knowledge  Engineering 

The  knowledge  engineering  phase  is  critical  to  the 
development  of  any  expert  system.  It  is  during  this  phase  that 
the  knowledge  of  the  human  expert  is  captured  for  inclusion  in  the 
knowledge  base  of  the  expert  system.  This  task  was  initiated 
during  a  two  week  visit  to  the  GPS  operations  center  at  Falcon 
AFS,  Colorado,  but  was  not  completed.  It  was  a  continuing  effort 
throughout  the  development  period.  Chapter  IV  addresses  the 
knowledge  engineering  effort  ir.  greater  detail. 

Identi f v  System  Reguirements 

Before  proceeding  to  select  an  expert  system  building  tool  or 
knowledge  representation  language  for  system  implementation,  the 
important  step  of  identifying  the  system  requirements  must  be 
accomplished.  As  a  result  of  the  knowledge  engineering  phase,  the 
necessary  input,  knowledge  base,  processing,  and  output 
requirements  can  and  must  be  stated  at  this  point  so  that  the  best 
tool  or  language  may  be  selected  and  the  proper  system  design 
developed.  Requirements  definition  is  actually  an  iterative 
process  requiring  the  developer  to  seek  feedback  from  the  users  at 
each  step  In  the  development  phase.  The  system  requirements  are 
identified  in  chapter  V. 
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System  Jaslgn 

The  first  step  toward  system  design  is  selection  of  an  expert 
system  building  tool  or  knowledge  representation  language  (KRL). 

A  KRL  can  provide  more  flexibility  to  a  knowledge  engineer,  but 
also  requires  much  more  programming  skill  and  effort.  An  expert 
system  building  tool  provides  a  structured  environment  to  work 
with,  requiring  less  programming  skill  and  effort,  but  it  may  be 
less  flexible.  Of  course,  there  are  also  cost,  hardware  and 
availability  constraints  which  must  be  taken  into  account.  For 
this  thesis,  only  tools  and  languages  available  at  AFIT  are 
considered  in  the  trade-off  analysis  outlined  in  Chapter  VI. 

Once  the  tool  or  language  is  selected,  the  real  work  of 
system  design  can  begin.  If  a  tool  rather  than  a  KRL  has  been 
selected,  then  the  design  process  is  scoped  since  the  knowledge 
representation  and  inferenclng  scheme  may  be  dictated  by  the 
chosen  software.  However,  the  manner  in  which  the  system 
requirements  will  be  satisfied  should  be  determined  prior  to  the 
implementation  phase.  The  knowledge  engineer  should  become 
intimately  familiar  with  his  software  during  this  phase. 

Implementation  and  Evaluation 

This  last  phase  is  an  iterative  one.  It  is  now  that  the 

prototype  is  actually  implemented  based  on  the  knowledge 

engineer's  design.  After  an  initial  system  is  developed  it  must 

be  evaluated  to  determine  if  it  is  operating  as  the  designer 

■* 

Intended  (verification)  and  if  its  conclusions  and  recommendations 
are  valid.  The  latter  step,  validation,  was  accomplished  by 
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presenting  NAVARES  with  three  anomaly  scenarios  used  to  evaluate 
satellite  engineers,  and  having  a  satellite  engineer  review  the 
system.  Chapter  VII  presents  the  results  of  the  evaluation  phase. 

Summary 

The  methodology  used  in  this  thesis  research  effort  is  based 
on  the  systems  approach  to  problem  solving.  The  overall  task  is 
broken  into  subtasks  which  are  accomplished  sequentially.  First, 
the  problem  had  to  understood.  Second,  a  satellite  program  was 
chosen.  Third,  an  in-depth  understanding  of  the  problem  and 
knowledge  used  by  the  expert  had  to  be  acquired.  Then.,  the  system 
requirements  could  be  defined,  software  selected,  and  a  design 
developed.  Finally,  the  system  is  implemented  and  evaluated  in  an 


iterative  fashion. 


Ill . 


Literature  Review 


Topic  Statement 

The  first  goal  of  this  review  is  to  present  three 
representative  expert  systems  that  deal  with  the  domain  of 
satellite  anomaly  resolution  (see  Table  I),  and  also  to  present 
the  current  plans  for  developing  expert  systems  to  support 
military  satellite  command  and  control,  specifically  anomaly 
resolution.  This  discussion  provides  insight  into  the  problem 
domain.  The  second  goal  is  to  present  a  summary  of  one  promising 
theoretical  approach  to  the  general  problem  of  fault  diagnosis, 
i.e.,  the  model-based  approach.  (References  12,  24,  and  28 
provide  a  good  Introduction  to  the  AI  field  for  those  without  a 
strong  background  in  this  area.  References  18  and  23  provide  an 
overview  of  expert  system  applications  to  Space  Operations). 

Anpl icat ions 

SCARES .  The  Satellite  Control  Anomaly  Resolution  Expert 
System  (SCARES)  is  a  prototype  developed  by  TRW.  Work  on  the 
prototype  began  in  late  1985  as  a  result  of  funding  from  the  Air 
Force  Satellite  Autonomy  Program  (SAP)  (13).  The  SAP  program 
manager  gave  the  Defense  Support  Program  (DSP)  System  Program 
Office  (SPO)  400K  to  develop  an  expert  system  prototype  to  perform 
anomaly  resolution.  The  SPO  chose  the  attitude  control  system 
(ACS)  on  the  DSP  satellites  as  the  problem  domain. 

The  motivation  for  the  project  came  from  the  desire  to 
develop  a  mobile  control  center  for  DSP  that  might  increase  the 
wartime  system  survivability.  A  system  like  SCARES  might  replace 
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Table  I.  Representati ve  Satellite  Diagnostic 
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the  expert  technical  advisors  who  would  not  accompany  a  mobile 
control  center.  Another  motive  for  developing  SCARES  was  to 
create  a  tool  that  the  technical  advisors  might  use  to  check  their 
own  work . 

TRtf's  engineers  limited  themselves  to  dealing  with 
?  subset  of  all  the  possible  ACS  anomalies  and  only  relatively 
simple  cases  (7).  A  demonstration  of  SCARES  was  conducted  in  late 
1986.  TRW  used  a  simulator  to  generate  30  to  40  anomaly  cases  for 
SCARES  (7).  SCARES  performed  as  well  or  better  than  human  experts 
given  the  same  anomaly  cases  (13). 

SCARES  is  no  longer  funded  by  the  Air  Force.  The  original 
contract  only  required  the  completion  of  the  initial  prototype. 
However,  TRW  has  used  their  own  internal  research  and  development 
money  to  continue  research  into  constructing  causal  models  and 
merging  the  rule-based  and  model-based  approaches  in  one  system 
(7)  . 

APRS .  The  Anomaly  Detection  and  Resolution  System  (APRS)  is 
an  internal  research  and  development  effort  underway  at  IBM 
Federal  Systems  Division  (FSD)  to  develop  a  generic  approach  to 
complex  military  system  control  (10:106-110). 

Ferneyhough  suggests  three  main  incentives  for  developing 
APRS  (10).  He  believes  that  APRS  can  improve  the  reliability  and 
survivability  of  complex  military  systems  and  reduce  their  life 
cycle  costs  (LCC) .  Reliability  can  be  improved  because  the  APRS 
can  check  the  decisions  of  novices  and  experts.  Survivability  can 
be  improved  if  the  APRS  allows  personnel  strength  at  control 
centers  to  be  cut  to  the  point  that  it  becomes  feasible  to  have 
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mobile  facilities  for  command  and  control.  Finally,  if  personnel 
strength  is  cut  there  will  be  corresponding  reductions  in  LCC. 

Ferneyhough  also  lists  some  requirements  for  ADRS .  Among 
these  requirements  are  the  need  for  the  system  to  be  embeddable 
into  the  existing  control  structure,  adaptable,  fast,  dynamic,  and 
economically  feasible  (10). 

The  general  ADRS  model  includes  six  components:  telemetry 
processing,  reference  model,  anomaly  diagnostician,  operator 
interface,  recovery  planner,  and  command  processing.  The 
telemetry  monitor  and  command  processor  handle  functions  that 
already  exist  in  today's  control  centers  and  need  not  be  discussed 
further.  The  reference  model  maintains  a  model  of  the  expected 
state  of  the  target  system  for  comparison  with  actual  telemetry 
data.  This  approach  allows  for  a  richer  representation  of  the 
knowledge  about  the  system  than  heuristic  rules  can  provide. 
Interactions  between  the  system  components  that  might  be 
overlooked  when  designing  a  rule-base  are  inherent  in  the  model. 
The  models  of  each  of  the  individual  components  are  based  on  rules 
and  variable  attributes.  The  variable  attributes  in  the  component 
models  allow  for  a  reduction  in  the  number  of  rules  required  in 
the  system  (10). 

The  anomaly  diagnostician  uses  heuristic  knowledge  to  narrow 
the  source  of  the  fault  to  one  element  of  the  system  and  flags 
this  information  to  be  presented  to  the  operator.  After  the  human 
operator  examines  the  system's  concli  ions  and  recommendations  the 
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recovery  planner  generates  command  sequences  to  resolve  the 
anomaly  In  accordance  with  the  anomaly  diagnostician's  and/or 
human  operator's  recommendations. 

IBM  has  developed  a  prototype  using  the  ADRS  concepts.  The 
target  system  was  the  Global  Positioning  System  Block  II 
spacecraft.  No  further  work  has  been  accomplished  on  ADRS  since 
the  prototype  was  demonstrated  as  sought  after  government  funding 
was  not  obtained  (22). 

STAR-PLAN .  Ford  Aerospace  began  development  of  the  Satellite 
Anomaly  Resolution  and  Planning  System  (STAR-PLAN)  in  1983  (11:1- 
3).  The  fact  that  STAR-PLAN  is  still  being  worked  on  today  makes 
it  one  of  the  oldest  satellite  command  and  control  projects  in 
existence.  The  system  is  now  in  its  third  phase  of  development. 

The  first  phase  of  Ford's  work  (STAR-PLAN  I)  was  targeted  at 
two  satellite  subsystems.,  the  electric  power  and  distribution 
system  (EPDS)  and  the  tracking,  telemetry,  and  command  (TT  &  C) 
system.  STAR-PLAN  I  monitors  telemetry  data,  alerts  humans  to 
possible  problems.  Isolates  faults,  and  suggests  corrections. 

STAR-PLAN  I  was  first  built  in  0PS5  on  a  VAX  11/780  then 
transferred  to  a  Xerox  1108  and  implemented  in  the  Knowledge 
Engineering  Environment  (KEE)  in  July,  1984  (11:3).  This  initial 
system  included  a  telemetry  simulator  for  closed  loop  testing. 
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The  designers  at  Ford  realized  that  there  were  limitations 
with  STAR-P.LAN  I.  They  needed  a  wider  variety  of  knowledge 
representation  techniques,  and  they  wanted  to  avoid  the 
limitations  imposed  on  the  system  by  having  to  define  all 
resolution  procedures  and  store  them  as  ioles  (27).  The  latter 
limitation  meant  the  system  could  never  handle  an  unanticipated 
anomaly. 

STAR- PLAN  II  separates  the  monitoring,  situation  assessment, 
diagnostic,  goal  determination  and  planning  functions  into 
modules.  The  monitoring  function  is  performed  by  the  Active  Data 
Base  which  sends  a  message  to  the  Situation  Assessment  module  if 
an  event  of  interest  has  occurred.  The  Situation  Assessment 
Module  picks  the  objects  (satellite  components)  involved  and  sends 
this  informatics.  on  to  th<»  Causal  Diagnosis  module.  The  latter 
module  performs  causal  analysis  to  determine  the  root  of  the 
problem  and  generates  a  list  of  which  objects  are  malfunctioning. 
When  this  list  of  malfunctioning  objects  is  received  by  the  Goal 
Determination  Module  it  identifies  the  goals  needed  to  resolve  the 
anomaly.  The  last  module.  Planning  and  Command,  creates  a  plan 
for  moving  from  the  currer  .  state  to  the  goal  state  and  determines 
the  sequence  of  commands  that  must  be  sent  to  the  satellite  to 
accomplish  resolution  of  the  anomaly. 
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The  data  indicate  a  standard  error  for  the  slope  of 
about  2.7%  which  would  still  not  reduce  the  value  of  enough 
to  fall  within  the  range  stated  in  Ref.  8, 

.012  <  §*  <  .020  (5) 

It  should  be  noted  that  there  is  a  good  deal  of 
uncertainty  in  the  values  to  assume  for  Kjq,  E  and  even  H.  For 
NC20 3  the  values  used  by  reputable  authors  vary  considerably, 
i.e.,  H  =  19.3  to  24.0  GPa;  E  =  420  to  448  GPa;  KIC  *  3  to  5.1 
MPa*M1/2.  While  the  absolute  value  for  would  be  affected  by 

the  choice  of  constants  this  would  not  account  for  the  disagree¬ 
ment  since  the  same  values  have  been  used  for  each  calculation. 

The  standard  error  estimate  for  the  experimental  slope 

is  less  than  3%  and  was  typical  of  the  error  found  in  this  study 

for  other  silicon  carbide  based  materials.  While  NC203  was  one 

of  the  materials  studied  in  Ref.  8,  the  logr i thmat ica 1 ly  plotted 

data  given  in  the  publication  can  not  be  read  accurately  enough 

for  a  direct  comparison.  This  material  was  not  one  chosen  as 

£ 

one  of  the  calibration  materials  for  calculating  §v< 

It  is  obvious  then  that  quite  small  changes  in  the  crack 

•j  /  2 

propagation  behavior  as  measured  by  the  slope  of  c  vs  P  can 
be  significantly  differentiated  but  that  reflecting  these 
changes  into  values  is  much  less  certain  due  to  uncertain¬ 

ties  in  the  other  constants. 

By  least  square  fitting  of  the  square  of  the  impression 
diagonals,  a2,  versus  load,  P,  as  the  independent  variable  the 
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This  second  version  of  STAR-PLAN  is  implemented  in  a  Ford 
developed  extension  of  KEE  called  "PARAGON"  (19:89).  PARAGON  is  a 
hybrid  knowledge  representation  scheme  that  incorporates  features 

i 

of  several  knowledge  representation  paradigms  (8:1-2).  The 
designers  attempted  to  capture  the  best  qualities  of  rules, 
objects,  classification  systems,  semantic  networks,  and 
blackboards . 

"*ne  version  of  STAR-PLAN  currently  under  development,  STAR- 
PLAN  lit,  is  also  Implemented  in  PARAGON  (18:35-36).  However,  the 
emphasis  in  this  phase  of  development  is  to  move  further  toward 
the.  model-based  approach,  to  reason  over  the  differences  between 
the  actual  telemetry  data  and  the  simulation  of  the  expected  state 
of  the  satellite.  "Differential  analysis  between  the  simulator 
and  the  actual  telemetry  data  will  be  the  primary  mechanism  for 
diagnosis  and  planning"  (9:1). 

Planned  Systems .  The  Air  Force  Satellite  Control  Facility 
(AFSCF)  with  the  help  of  the  Aerospace  Corporation  and  the  NASA 
Ames  Research  Center  is  preparing  to  contract  for  four  expert 
system  research  efforts  to  support  their  operations  (1;4).  Two  of 
these  research  efforts  fall  within  the  satellite  anomaly 
resolution  domain.  One  is  the  funding  of  continued  research  with 
STAR-PLAN.  The  other  is  development  of  en  Intelligent  Satellite 
Monitor  (ISM)  for  DSP. 

These  two  efforts  use  two  different  approaches  to  satellite 

v 

anomaly  resolution.  The  first  effort,  STAR-PLAN,  will  continue 
progress  toward  developing  an  expert  system  using  the  mcdel-based 
approach  that  may  be  able  to  handle  unanticipated  anomalies.  This 
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effort  will  no*;  produce  an  operational  system  in  the  near  term 
since  model-based  systems  are  relatively  new  and  complex  when 
compared  to  the  more  familiar  rule-based  systems.  Kruchten 
suggests  that  the  inability  of  today's  expert  systems  (rule-based) 
to  handle  unanticipated  anomalies  makes  them  virtually  useless 
(15>.  Success  with  STAR-PLAN  could  quiet  such  complaints. 

The  second  effort,  ISM,  is  a  response  to  the  need  for 
monitoring  the  on-orbit  spares  In  the  DSP  constellation  (2;4). 

The  goal  for  ISM  is  not  to  accomplish  in-depth  anomaly  resolution 
for  the  satellite,  but  simply  to  alert  the  human  operators  if  a 
problem  develops  aboard  one  of  the  spares.  ISM  will  continuously 
monitor  the  satellites'  telemetry  data,  freeing  humans  from  this 
task.  Since  ISM  will  not  be  required  to  perform  in-depth 
diagnosis  and  remedy  tasks  the  rule-based  approach  could  be  used. 

The  Rome  Air  Development  Center,  managing  the  USAF  Satellite 
Autonomy  Program,  is  also  funding  research  in  satellite  anomaly 
resolution  (16).  Contracts  were  recently  awarded  to  Ford 
Aerospace,  TRW,  and  Boeing  for  research  into  on-board  satellite 
diagnostic  systems. 

Modal -based  Approach 

The  term  "model-based"  refers  to  a  general  approach  to 
diagnostic  systems.  These  systems  "detect  failures  by  identifying 
discrepancies  between  observed  and  expected  system  behavior" 

(3:9).  The  "model"  in  "model-based"  refers  to  the  description 
of  the  normal  system  that  is  used  as  a  reference  for  comparison. 
This  model  may  be  qualitative,  quantitative,  or  hybrid  (mix  of 
quantitative  and  qualitative  modelling)  (3:9-10).  In  hybrid 


system  the  qualitative  code  usually  acts  as  the  high  level 
control/  calling  lower  level/  quantitative  portions  of  the  model 
as  "subroutines'*  (3:10). 

One  of  the  semine.l  worj.s  in  this  field  was  an  attempt  to 
conduct  diagnostic  reasoning  based  on  structure  and  behavior. 

This  approach  modelled  the  target  system  as  a  network  of 
subsystems  with  the  ".iwest  level  components  treated  as  'black 
boxes'  which  are  governed  by  one  ox  more  constraint  relations. 
Faults  are  declared  whenever  the  observed  behavior  differs 
significantly  from  the  expected  constrained  behavior"  (3:9).  This 
work  also  introduced  the  concept  of  "adjacency."  "Devices 
interact  because  they  are  in  some  sense  adjacent  -  electrically 
adjacent  (wired  together),  physically  adjacent  (her.ee  thermally 
connected),  eiectromagnetically  adjacent  (not  shielded)  etc" 

(3:9). 

Many  proponents  of  this  approach,  and  of  the  model-based 
approach  in  general,  suggest  that  such  a  system  can  handle 
unexpected  or  unanticipated  anomalies,  but  given  the  the 
description  of  "adjacency,"  one  can  see  that  modelling  any  complex 
physical  system  is  extremely  challenging  (15; 3: 12).  ,  Some  faults 
will  be  extremely  difficult  to  diagnose  since  they  result  from  an 
unanticipated  interaction  between  "adjacent"  components. 

Conclusion 

The  applicability  of  expert  systems  technology  to  the 
problems  of  military  satellite  command  and  control,  specifically 
anomaly  resolution,  is  recognized  in  the  U.S.  Air  Force  and  the 
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defense  Industry.  Several  research  efforts  demonstrate  that  an 
expert  system  based  on  rules  alone  is  seriously  limited  in  that  it 
cannot  deal  with  unanticipated  anomalies.  However,  the  model- 
based  approach  to  expert  system  design  may  avoid  this  limitation. 
ADRS  and  STAR-PLAN  demonstrate  potentially  successful  designs. 

Since  model-based  expert  systems  also  entail  much  greater 
complexity,  cost,  and  technology  levels,  along  with  their  better 
performance,  they  may  not  be  successfully  developed  for  several 
years.  In  this  event  the  simpler  and  cheaper  rule-based  approach 
can  be  used  to  solve  less  demanding  problems. 
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IV.  Knowledge  Engineering 


Introduction 

During  the  two  week  visit  to  Falcon  AFS,  a  great  deal  of 
effort  was  spent  in  simply  understanding  the  problem.  Regardless 
of  the  fact  that  a  literature  review  and  telephone  interviews  had 
been  conducted  to  gain  an  understanding  of  the  anomaly  resolution 
process,  there  remained  the  possibility  that  close  examination  of 
the  GPS  command  and  control  process  would  yield  a  better 
application  or  prove  GPS  satellite  anomaly  resolution  an 
unsuitable  domain  for  expert  system  applications. 

The  2  SCS  introductory  course  provided  some  necessary 
background  and  understanding  of  GPS  operations  before  spending  two 
days  in  tne  MCs  with  the  Satellite  Engineer ing  Officers  {SECs}. 

The  SEOs  provide  the  first  level  of  anomaly  resolution  for  the 
satellites.  It  is  their  responsibility  to  identify  Satellite 
Vehicle  (SV)  anomalies  and  resolve  them  if  possible.  If  the 
anomaly  is  serious  enough  to  threaten  the  health  of  the  SV  and 
cannot  be  corrected  immediately,  it  is  the  SEO's  responsibility  to 
reconfigure  the  SV  so  that  it  is  safe  from  further  degradation. 

The  remainder  of  the  visit  was  spent  gathering  data, 
attending  classroom  sessions  covering  the  SV  subsystems  and 
requirements,  and  interviewing  Satellite  Engineers  (SEs)  who 
nerform  the  second  level  of  anomaly  resolution,  those  not  on  the 
operational  crews.  It  is  the  latter  group  of  SEs  who  perform  in- 
depth  anomaly  resolution.  These  SEs  are  military  officers  who  are 
rssigned  to  monitor  the  long  term  status  of  one  particular  SV 
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subsystem  and  resolve  anomalies  as  required.  They  are  also  the 
authors  o£  the  anomaly  case  reports  which  serve  as  a  source  o£ 
knowledge  for  NAVAEES . 

Background  on  GPS 

Mission.  The  NAVSTAR/GPS  is  a  space-besed  radio  navigation 
system  designed  to  provide  U.S.  and  Allied  land,  sea  and  air 
forces  with  worldwide,  three  dimensional  position  and  velocity 
information.  It  also  has  a  Nuclear  Detonation  (NUDBT)  detection 
capability. 

Current  Operations .  Satellite  support  includes  the  dally 
uploading  of  navigation  information  into  the  operative  SVs,  the 
monitoring,  diagnosis  and  reconfiguration  of  all  SVs  in  the  GPS 
constellation,  activation  of  spare  SVs,  SV  station  keeping,  SV 
repositioning,  and  recovery  of  unstable  SVs. 

Each  SV  is  provided  three  navigation  uploads  per  day. 
Normally,  a  contact  with  the  SV  also  includes  a  State  of  Health 
(SOH)  support  which  entails  monitoring  of  the  telemetry  that 
Indicates  the  satellite's  health.  The  SOH  support  must  be 
accomplished  four  times  dally. 

A  typical  contact  would  consist  of  a  navigation  message 
upload  and  SOH.  The  Satellite  Analysis  Officer  (SAO)  would 
prepare  the  navigation  message  for  sending  prior  to  the  pass, 
while  the  Satellite  Operations  Officer  (S00)  would  prepare  to 
transmit.  If  any  commands  were  to  be  sent,  the  SEO  would  have 
generated  them  and  the  S00  would  also  prepare  the  Ground  Antenna 
(GA)  to  send  these  S-band  signals.  When  the  satellite  is 
initially  contacted  by  the  GA  it  begins  transmitting  its  telemetry 


data  in  real-time,  refreshing  the  information  in  the  telemetry 
every  second.  The  SOO  monitors  critical  points  and  calls  upon  the 
SEO  if  there  are  any  indications  of  a  possible  problem  aboard  the 
SV.  The  SEO  monitors  all  the  telemetry  points  tor  possible 
problems  regardless  of  queries  from  the  SOO.  The  SEO  also  records 
many  items  for  short  term  trend  analysis  of  the  SV's  health.  If 
there  actually  is  a  problem  on  the  SV,  ti.e  anomaly  resolution 
process  begins.  This  process  will  be  discussed  in  detail  in  the 
next  section. 

Once  all  the  commands  and/or  navigation  data  is  sent  and 
monitoring  is  completed,  the  GA  ceases  its  transmission  of  the  S- 
band  signal  to  the  SV  and  the  telemetry  downlink  automatically 
terminates  after  16  seconds. 

Current  Anomaly  Resolution  Process 

This  section  describes  the  anomaly  resolution  process.  The 
various  types  of  anomalies  are  presented  and  responsibilities  of 
operations  personnel  defined.  The  Research  and  Development 
(RD)  community  uses  different  definitions  and  terminology  than  the 
operational  community  in  describing  anomaly  categories  and 
procedures,  but  only  the  operational  community's  terms  will  be 
used  here.  The  matrix  in  Table  II  provides  a  classif ication  of 
anomaly  resolution  responsibilities  that  may  be  useful  to 
illustrate  this  section. 
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Table  11.  MAUSTAR  Anonaly  Resolution 


Types  of  Anomalies .  The  2  SCS  Operational  Directive  on  SOH 
and  anomaly  resolution  lists  three  categories  of  anomalies  (25). 

1.  Category  1  -  SV  life  threatening 

2.  Category  2  -  SV  mission  threatening 

3.  Category  3  -  All  others 

Table  III  illustrates  these  concepts.  Contingency  actions  to 
correct  anomalies  are  identified  as  type  "A",  if  the  appropriate 
response  to  the  anomaly  is  defined  in  an  Operational  Directive  or 
the  Orbital  Operations  Handbook  (OOH),  or  type  MBM,  if  the 
respo r  ?  is  not  documented. 

For  example,  if  there  was  an  anomaly  detected  in  the  TTC  or 
EPS  such  that  the  satellite  would  permanently  lose  its  operational 
capability  if  it  were  not  corrected  immediately,  then  this  would 
be  a  Category  1  anomaly.  If  this  Category  1  anomaly  was  one 
already  ticipated  by  the  satellite  designers,  or  one  already 
seen  and  solved  in  the  past,  then  it  is  likely  that  there  would 
be  a  documented  procedure  in  the  OOH  or  Operational  Directives  for 
use  in  resoi  ing  this  problem.  This  would  be  a  type  "A" 
contingency  action.  On  the  other  hand,  if  an  anomaly  was 
encountered  in  the  NAV  subsystem  that  was  serious  enough  to 
threaten  the  usefulness  of  navigation  data,  but  not  the  health  of 
the  SV,  It  would  be  called  a  Category  2  anomaly.  If  this  anomaly 
was  not  anticipated  by  the  satellite  designers  or  seen  previously, 
it  would  likely  be  a  type  "B"  contingency  action. 
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es  of  Anomalies 
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SEP  Fnnct 1 ons .  The  SEP  was  described  earlier  as  the  crew 
member  performing  the  first  level  of  anomaly  resolution.  This  is 
true  since  in  most  cases  he  will  be  the  first  person  to  discover 
the  problem.  The  SEO  checks  his  displays  for  telemetry  points 
which  are  flagged  with  yellow  or  red  color  to  indicate  a  reading 
out  of  normal  limits. 

The  SEO's  first  step  would  be  to  draw  upon  her  knowledge  of 
the  SV's  configuration  and  health  to  determine  if  an  anomaly 
actually  existed.  Failing  to  resolve  the  problem  at  that  point, 
the  SEP  may  check  the  PPH  for  a  procedure  to  follow.  If  a 
procedure  existed,  it  would  be  a  type  MA"  anomaly.  Depending  on 
the  seriousness  of  the  anomaly,  the  SEP  may  recommend  immediate 
action,  request  support  from  the  on-call  SE,  or  simply  make  note 
of  the  condition  so  that  the  appropriate  subsystem  SE  can 
investigate  the  matter.  If  the  anomaly  were  serious  enough,  and 
no  procedure  was  available,  the  SEP  may  then  construct  a  plan  for 
resolving  the  problem.  To  do  this,  he  would  again  refer  to  the 
procedural  information  in  the  OPH  or  Pperational  Directives.  Of 
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course,  he  may  also  rely  on  his  general  knowledge  and  training, 
but  the  SEO's  knowledge  is  typically  more  general  and  shallow  than 
the  subsystem  expert's,  the  SE.  For  this  reason,  the  SEO's  are 
directed  to  call  in  the  SE's. 

SE  Functions .  The  SE's  do  not  work  on  the  operational  crews 
except  to  maintain  proficiency  as  an  operator.  They  typically 
spend  the  majority  of  their  time  performing  long  term  analysis  of 
the  performance  of  their  particular  subsystem  on  board  each  SV, 
increasing  their  knowledge  and  understanding  of  their  assigned 
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subsystem,  supporting  the  operational  crews  by  developing 
contingency  plans  for  possible  anomalies,  and  last,  but  certainly 
not  least  important,  resolving  anomalies. 

The  SE’s  use  a  variety  of  software  on  microcomputers  to 
perform  a  great  deal  of  their  trend  analysis  and  trouble-shooting. 
Often,  they  can  anticipate  problems  using  this  trend  analysis,  or 
go  back  to  the  trend  analysis  to  investigate  an  anomaly.  They  may 
also  rely  on  the  OOH  to  assist  them  in  resolving  a  problem,  but 
are  more  likely  to  use  their  knowledge  of  the  history  of  the 
satellites  and  basic  engineering  skills.  For  this  reason  they 
must  be  considered  the  best  source  of  knowledge  for  NAVARES. 

A  particularly  good  source  of  the  SEs'  knowledge  can  be  found 
in  the  anomaly  case  reports.  Whenever  there  is  a  significant 
auoiTialy  on  an  SV,  one  SE,  usually  the  one  assigned  to  the  effected 
subsystem,  is  assigned  to  lead  the  resolution  effort.  This  SE 
will  produce  a  report  of  the  anomaly  upon  completion.  These 
reports  usually  contain  a  narrative  description  of  the  events  and 
describe  the  logic  used  to  arrive  at  the  conclusion. 

Summary 

This  section  has  presented  some  background  on  GPS  and  an 
explanation  of  anomaly  resolution  procedures.  With  the  knowledge 
engineering  complete,  system  requirements  can  be  addressed. 
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V.  System  Requirements 


Introduction 

The  system  requirement?  for  the  prototype,  NAVARES,  are 
separated  into  four  categories:  input,  knowledge  base,  processing, 
and  output.  Tables  IV,  V,  VI,  and  VII  illustrate  the  results 
of  the  system  requirements  analysis.  Each  table  lists 
requirements  along  the  left  hand  side.  The  columns  reflect  the 
current  methods  of  satisfying  the  requirements,  the  methods  and 
degree  of  satisfaction  with  the  thesis  prototype,  and  the  methods 
and  degree  to  which  an  operational  system  should  satisfy  the 
requi cements . 

Input 

TaDle  IV  illustrates  the  system  input  requirements.  The  SEOs 
record  the  values  of  telemetry  points  during  all  SOH  supports. 

Prom  these  records,  as  well  as  the  trend  plots,  the  SEs  obtain  the 
bulk  of  the  input  needed  to  perform  trend  analysis  and  anomaly 
resolution.  It  is  also  possible  to  play  back  recordings  of 
telemetry  data  from  recent  SOH  supports. 

An  operational  system  should  1  sceive  the  telemetry  data  via  a 
computer  interface  for  trend  analysis  and,  perhaps,  for  raw  input 
to  be  reasoned  over.  In  general,  the  prototype  will  not  require 
telemetry  point  values  as  input.  It  may  only  require  selected 
points  to  be  entered,  needing  more  conceptual  or  abstract 
information  about  the  SV  status  and  environment  to  reach  a 
conclusion . 
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Table  IV.  System  Requirements i  Input 
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Figure  11.  Weibull  plot  for  331-28B  samples  from  various 

furnace  trays  in  a  single  batch.  Lines  1,2,3  are 
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With  experience,  new  heuristics  for  anomaly  resolution  are 
formulated.  Currently,  these  new  heuristics  may  be  reflected  in 
the  Operational  Directives,  OOH  updates,  anomaly  reports,  and  the 
minds  of  the  SEs.  For  an  expert  system  to  be  useful,  it  must  be 
updated  to  reflect  these  changes. 

As  an  SV  ages,  its  configuration  will  change  to  adapt  to 
failed  components  or  to  new  mission  requirements.  The  current 
status  of  each  SV's  configuration  is  maintained  by  the 
Standardization  and  Evaluation  section  (DOV)  in  a  word  processor 
(Wordstar)  file.  This  knowledge  of  the  SVs 1  configuration,  along 
with  knowledge  of  each  SV's  peculiarities,  should  be  incorporated 
into  any  system,  and  must  be  modifiable  to  keep  it  current. 

Knowledge  Base 

Table  V  illustrates  the  system  knowledge  base  requirements. 

As  already  discussed,  past  anomaly  case  reports  can  provide 
valuable  background  for  the  SE.  The  thesis  prototype  includes  a 
data  base  fi.e  of  past  report  titles  with  associated  retrieval 
keys . 

There  are  three  levels  of  knowledge  involved  in  the  anomaly 
resolution  process.  There  is  procedural  knowledge  that  comes  from 
the  OOH  and  Operations  Directives  which  is  very  much  like  the 
knowledge  incorporated  into  a  checklist.  The  second  level 
corresponds  to  anomaly  resolution  heuristics  which  are  developed 
through  experience.  Such  knowledge  may  also  be  found  in  the  OOH 
and  Operations  Directives,  but  is  more  likely  to  be  found  in  the 
anomaly  case  reports  and  the  SEs'  heads.  The  third  level  of 
knowledge  is  much  more  basic  and  may  be  described  as  reasoning 
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Tablt  V.  S»tt»n  Recuircntntst  Knowledge  Bast 


This  knowledge  is  based  less  on 


from  "first  principles . r 
procedures  or  operational  experience  and  more  cm  an  understanding 
of  physical  relationships  and  scientific  or  engineering  laws. 

This  knowledge  is  found  in  the  SEs '  and  the  satellite  designers* 
minds.  It  ie  gained  through  education  and  training. 

Onlj*  the  first  two  levels  of  knowledge  are  incorporated  into 
the  prototype.  operational  system  might  incorporate  the  third 

level  of  knowledge  via  the  model-based  approach.  Additionally,  an 
operational  system  should  handle  problems  with  any  of  the  nine 
subsystems,  but  a  prototype  can  demonstrate  the  applicability  of 
expert  systems  without  covering  the  entire  SV.  Based  on  the 
relative  importance  and  likelihood  of  failure  of  each  subsystem, 
the  AVCS  and  EPS  were  selected  for  implementation  in  NAVARES. 

Processing 

Table  VI  illustrates  the  system  processing  requirements.  The 
individual  SE  responsible  for  a  particular  subsystem  of  the  SV 
will  monitor  trending  data  and  produce  plots  as  necessary.  As 
discussed  earlier,  these  plots  contribute  significantly  to  the 
anomaly  resolution  process,  and  are  created  with  PC  based 
software.  The  thesis  prototype  does  not  interface  with  this  trend 
analysis  software,  but  an  operational  system  should  include  this 
capability. 

The  SEs  use  a  PC  file  to  store  the  more  recent  anomaly 
reports.  This  file  allows  the  user  to  perform  a  search  for 
relevant  reports.  The  thesis  prototype  performs  a  data  base 
search  for  the  same  purpose. 


Table  VI.  Systcn  Retju  irenents:  Processing 


The  process  of  diagnosis  and  remedy  of  satellite  problems  is 
a  complex  one  and  varies  depending  on  severity  and  whether  or  not 
a  problem  was  anticipated  or  seen  before.  However,  one  can 
simplify  matters  by  narrowing  the  problem  to  a  particular 
subsystem.  Usually,  the  SE  makes  his  best  guess  then  runs 
diagnostic  tests  or  conducts  analysis  to  verify  his  hypothesis. 

The  thesis  prototype  is  more  limited  in  its  diagnostic  prowess. 

It  only  provides  one  solution  to  the  user.  An  operational  system 
should  suggest  any  possible  solutions  to  the  user  indicating  which 
are  more  probable. 

Output 

Table  VII  illustrates  the  system  output  requirements. 
Historical  plots  of  selected  telemetry  points  are  very  useful  to 
the  SE  in  anticipating  and  resolving  SV  anomalies.  Currently, 
there  is  a  computer  interface  between  the  mainframe  and  an  IBM  PC 
microcomputer  or  the  MCS  operations  floor  which  allows  important 
telemetry  points  to  be  loaded  onto  a  floppy  disk.  The  data  is 
then  transferred  to  a  Zenith  248  microcomputer  in  the  analysis 
room  adjacent  to  the  MCS  operations  floor.  Here,  the  SEs  can  use 
graphics  and  spreadsheet  software  to  generate  their  plots.  If  the 
desired  telemetry  points  are  not  transferred  along  the  computer 
interface,  then  the  data  must  be  hand  plotted  or  manually  entered 
into  the  Z-24B  for  plotting.  The  thesis  prototype  does  not 
include  the  capability  to  generate  these  plots,  but  an  operational 
system  should. 
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Table  MIX.  System  Requirement*!  Output 


If  they  do  not  already  exist  in  the  OOH  or  Operational 
Directives,  contingency  plans  for  anomaly  resolution  are  developed 
manually.  These  plans  outline  the  logic  and  steps  to  be  taken  to 
diagnose  and  remedy  the  problem.  They  may  also  include  the 
specific  command  blocks  to  be  sent  to  the  SV. 

The  anomaly  report  is  completed  by  the  responsible  SB  and 
summarizes  the  events,  logic,  and  results  of  a  particular 
anomaly's  resolution.  The  reports  have  a  general  format,  not  a 
rigid  structure.  They  may  include  references  such  as  trend  plots 
to  illustrate  a  point  or  provide  background.  The  thesis  prototype 
provides  a  final  report  including  the  diagnosis,  remedy,  and 
results  of  the  past  report  data  base  search. 

The  hundreds  of  anomaly  reports  completed  while  Satellite 
Control  Authority  (SCA)  resided  with  the  AFSCF  are  on  file  in  the 
analysis  room  in  hardcopy  form.  They  are  organized 
chronologically,  but  are  not  catalogued.  The  first  2  SCS  anomaly 
report  was  created  in  May  1986,  shortly  after  SCA  was  transferred 
to  the  MCS .  Since  the  SCA  transfer  the  2  SCS  has  issued  about  one 
dozen  reports  which  they  store  in  hardcopy  and  electronic  form. 

The  thesis  prototype  saves  its  final  report  in  a  text  file.  An 
operational  system  should  allow  the  user  to  add  text  and  graphics 
(trend  analysis  plots)  to  the  system  output. 

Summary 

The  requirements  presented  in  this  chapter  went  through 
several  iterations.  They  provide  the  foundation  for  the  system 
design  and  will  undergo  further  Iterations  as  a  result  of  the 
users'  evaluation  of  the  thesis  prototype. 
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VI .  System  Design  and  Implementation 

Introduction 

The  process  of  design  and  implementation  translated  the 
requirements  presented  in  the  last  chapter  into  a  functioning 
prototype.  This  chapter  provides  an  overview  of  this  process. 

The  first  step  was  to  select  the  best  software  tool  for 
development.  The  second  step  was  to  design  and  implement  a 
prototype  to  meet  the  system  requirements. 

Tool  Trade-off  Study 

The  tools  selected  for  examination  were  limited  to  those  that 
can  be  run  on  an  IBM  PC  compatible  microcomputer  since  the  SEs  use 
Z-248s  and  these  machines  are  also  available  at  AFIT.  The  tools 
were  also  limited  to  those  available  at  AFIT  and  those  suited  to 
the  problem  domain  of  diagnosis  and  prescr iption,  generally,  a 
tool  capable  of  backward  chaining  or  goal  directed  inferencing. 

Based  on  the  definition  of  system  requirements,  the  tool 
required  the  following  attributes. 

1.  Interfaces  with  data  bases  and  spreadsheets  are  required. 
The  capability  to  interface  with  external  programs  and  text  files 
is  not  required,  but  may  prove  useful. 

2.  The  tool  should  be  very  user  friendly.  Specifically,  it 
must  have  an  explanation  facility,  use  easily  understood  syntax 
rather  than  cryptic  computer  code,  and  be  modifiable  by  the  user 
who  is  assumed  to  be  experienced  in  using  computers,  but  not  a 
programmer . 
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3.  Traces  and  useful  error  messages  can  speed  development 
and  improve  the  possibility  that  the  system  can  be  modified  by  the 
user . 

4.  The  tool  must  be  relatively  inexpensive. 

5.  The  knowledge  base  requirements  include  some  capability 
for  uncertainty  reasoning  and  the  capability  to  represent 
knowledge  about  all  nine  subsystems  for  an  operational  system. 

Table  VIII  lists  five  tools  across  the  top  of  a  matrix  with 
five  feature  groupings  listed  along  the  left  hand  side.  Turbo 
PROLOG  was  included  in  this  table  since  one  of  the  2  SCS  engineers 
who  may  participate  in  developing  NAVARES  into  an  operational 
system  has  experience  with  this  programming  language.  However,  as 
illustrated,  it  does  not  have  several  of  the  requi~ed  features. 

KES  and  Insight  2+  would  be  fair  choices,  but  they  do  not 
include  the  capability  to  interface  with  spreadsheet  programs  or 
text  files.  In  addition,  KES's  syntax,  while  being  easier  to 
understand  than  traditional  programming  languages,  is  more  cryptic 
than  the  remaining  tools. 

The  two  tools  which  satisfied  the  most  requirements  were  VP 
Expert  and  Guru.  One  major  difference  between  these  tools  is 
price.  This  difference  can  be  explained  in  part  by  the  fact  that 
Guru  includes  data  i>u.3^s,  .  steads heets,  text  processing,  graphics, 
a  procedural  language,  statistical  analysis  software,  and  many 
other  features.  VP  Expert  only  includes  the  capability  to 
Interface  with  such  software  «s  data  bases,  spreadsheets,  and 
procedural  languages.  VP  Expert  is  also  much  more  limited  in  its 
inferencing  strategy,  uncertainty  reasoning,  and  user  interface. 
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INSIGHT  2+  W  EXPERT  GURU  ^ 


Table  Mill.  Tool  Selection  Matrix 


But  the  most  serious  limitation  for  VP  Expert  is  in  memory.  Mo 
knowledge  base  can  exceed  approximately  30K  of  memory  or  a  logical 
chain  of  more  than  20  rules.  The  only  way  to  avoid  this 
limitation  is  to  separate  the  knowledge  base  into  appropriately 
sized  modules  which  can  be  linked  together  by  chaining  from  one  to 
another.  The  producers  of  VP  Expert  claim  that  this  memory 
limitation  will  be  corrected  with  the  next  release. 

Due  to  the  serious  limitations  of  VP  Expert  it  was  not  used 
for  this  effort.  Since  Guru  is  the  only  tool  examined  that  met  all 
the  system  requirements  it  was  the  tool  used  to  build  the 
prototype . 

System  Design  and  Implementation 

Introduction .  Rapid  prototyping  was  the  design  strategy  used 
to  develop  NAVARES.  First,  several  small  systems  were  developed 
to  explore  Guru's  capabilities.  Then  a  rule  set  was  developed  to 
handle  the  AVCS.  As  proficiency  with  the  tool  increased, 
procedural  code  was  added  for  control,  and  the  remaining  rule  sets 
were  created.  Design  was  an  evolutionary  process. 

Before  the  tool  trade-off  study  was  conducted  NAVARES'  system 
design  structure  was  apparent.  Figure  1  illustrates  the  three 
levels  of  knowledge  described  in  the  knowledge  engineering  and 
system  requirements  discussion.  The  current  NAVARES  prototype  is 
a  partial  implementation,  handling  only  the  AVCS  and  EPS  with  no 
model  base.  From  this  high  level  description  it  was  clear  that 
the  operational  system  would  need  to  Incorporate  a  variety  of 
knowledge  representation  techniques.  However,  for  the  initial 
prototype  the  "if-then''  rules  of  Guru  would  be  adequate  to 
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represent  the  anomily  resolution  heuristics  documented  in  the  OOH 
and  past  anomaly  case  reports. 

A  Guru  knowledge  base  may  be  composed  of  rules  in  one  or  many 
files  called  "rule  sets"  (20).  NAVARES  includes  seven  rule  sets 
which  are  called  by  and  include  Guru  procedural  code.  The 
majority  of  the  system  variables  are  global  so  that  facts  known  at 
any  point  during  the  program's  execution  are  available  to  any  rule 
set.  NAVARES  also  takes  advantage  of  the  data  management 
capabilities  of  Guru  by  storing  titles  ar.d  retrieval  keys  for  past 
anomaly  reports  which  may  be  presented  to  the  user  at  the  end  of  a 
session.  The  remainder  of  this  chapter  describes  the  knowledge 
representation,  data  management,  user  interface.  and  output. 
Appendix  ".V*  provides  further  details  which  may  be  needed  for 
system  maintenance . 

Knowledge  Representation.  The  knowledge  engineering  process 
never  revealed  a  standard  approach  to  the  process  of  anomaly 
resolution.  The  experts  uje  their  experience  and  knowledge  to 
analyze  each  anomaly  as  a  unique  challenge.  Thus,  a  structure  for 
representing  NAVARES'  knowledge  was  induced  from  a  collection  of 
past  reports  and  the  OOH.  This  structure  is  represented  in  Figure 
2.  At  the  top  of  the  illustration  are  the  subsystems  that  the 
user  may  choose  as  the  suspected  culprit  in  the  anomaly.  If 
"Unknown"  is  chosen,  then  the  system  will  consider  all  the 
possible  anomalies  included  in  its  knowledge  base.  If  the  AYCS  or 
EPS  is  chosen,  then  the  system  restricts  its  search  for  a  disorder 


UNKNOWN 


and  remedy  to  those  anomalies  applicable  only  to  the  selected 
subsystem.  (TAVARES  performs  backward 'Chaining,  depth-first 
search  with  "remedy"  as  the  goal). 

Next,  there  are  five  different  circumstances  from  which  the 
user  must  choose  one  as  the  condition  under  which  the  anomaly 
occurred.  Note  that  the  largest  part  of  NAVARES'  knowledge  :alls 
in  the  -'Normal  Ops"  area.  Under  the  AVCS,  the  user  may  also 
specify  Delta-V  Maneuver  execution.  Spin  Stabilization,  or  Dual 
Magnet  Momentum  Dump  as  the  circumstance.  Under  the  EPS,  he  may 
select  Normal  Ops  or  Battery  Reconditioning.  The  four 
circumstances  outside  of  Normal  Ops  are  logically  separate  subsets 
of  rules  that  apply  only  to  these  particular  circumstances 
(indicated  by  the  lightly  shaded  areas).  Figure  3  shows  a  sample 
rule  from  this  layer  of  the  knowledge  base. 


RULE: 


epsld 
READY : 


IF: 
THEN : 


REASON; 


once 

@3,1  ?"What  were  the  circumstances  of  the 
anomalous  event?" 

event  =  MENU (epsmenu,  1, 2, 7, 22,  5,  36,  .1 ) 

6  24,1  ?"Thinking . . .  please  wait." 
event  *  1 
askl  -  true 
clear 

@3,1  ?"Please  narrow  the  problem  to  one  of 
the  following  categories." 
normvent  =  MENU( normenu, 1, 5,  5, 21,  3, 38, 1 ) 

@  24,1  ?"Think ing . . .  please  wait." 
if  normvent  ne  5  then  eperun  =  true 
perform  smallkbs 

endi  f 

Narrowing  search  for  disorder  to  particular 
circumstances . 


Figure  3.  Sample  Circumstance  Selection  Rule 


44 


Under  Normal  Ops,  there  are  nine  subgroups.  These  subgroups 
correspond  to  component  groups  or  narrow  areas  for  the  system  to 
search  for  a  solution.  The  three  lightly  shaded  subgroups,  (i.e.. 
Loss  of  Earth,  Load  Shed  -and  Solar  Array},  are  areas  where  the  EPS 
and  AVCS  overlap.  This  overlap  is  Indicated  by  the  dotted  lines. 
To  the  left  of  the  lightly  shaded  subgroups  are  those  subgroups 
which  logically  fall  under  the  AVCS.  To  the  right  are  those  which 
fall  under  the  EPS,  This  subgroup  layer  in  intentionally 
portrayed  as  the  thickest  since  this  is  the  area  where  the  bulk  of 
N  AVARS- S '  knowledge  resides. 

The  bottom  two  layers,  "Disorder”  and  "Remedy,"  consist  of 
rules  which  match  evidence  {  i.e.,  SV  status  information  obtained 
from  the  user)  to  a  disorder  and  a  disorder  to  a  remedy, 
respectively.  Figures  4  and  5  sho*r  a  sample  rule  from  each  of 
these  layers. 


RULE:  rodump4 

IF;  chkhow  =  true  and 

momhlgh  -  *’Y"  and 
rod  Ion  =  "Y"  and 
(howflag  =  "Y"  or 
tbedtemp  =  *¥'* ) 

THEN:  disorder- "uncommanded  thruster  dump" 

clear 

?"'fhe  SV  may  have  experienced  an  uncommanded" 
?”thr uster  dump.  (See  MCS-9794-01 )" 
dl--MThe  SV  may  have  experienced  an  uncoimanded” 
d2=”thruster  dump.  (See  MCS-9794-01 ) " 

REASON:  If  the  momentu>ns  on  the  previous  passes  were 

high  and  building,  and  the  Momentum  Dump  Logic 
( HDL )  was  on,  and  we  had  either  a  flag  in  the 
HOW  word  or  high  thruster  bed  temperatures, 
then  we  may  have  had  an  uncommanded  thruster 
dump.  See  KCS-9794-01. 


Figure  4.  Sample  Evidence  to  Disorder  Rule 
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-  -rmm  A'  “  ' "  “ 

RULE: 

i>at8i 

IF: 

d isorder="probable  battery  failure" 

THEN : 

remedy  =  true 

■p  «  H  .  «  M 

?*Turn  off  the  charger  to  the  failed  battery." 
rl="Turn  off  the  charger  to  the  failed 
battery." 

REASON . 

See  GQH  Figure  3. 8. 2. 3-3. 

Figure  5.  Sample  Disorder  to  Remedy  Rule 

Figure  2  does  not  show  the  organization  of  the  knowledge 
base  into  Guru  rule  sets.  NAVARES  includes  seven  rule  sets. 

There  are  four  specific  or  narrow  rule  sets  whicn  must  handle 
anomalies  for  Yaw,  Battery,  Load  Shed  and  Solar  Array  related 
problems,  respectively.  These  four  may  be  executed  by  three  more 
•general  rule  sets  for  the  AVCS,  EPS  and  Unknown  subsystem, 
respectively.  This  organization  allows  for  manageably  sized 
groups  of  rules  and  acceptable  execution  times. 

Execution.  Although  transparent  to  the  user,  NAVARES  is 
driven  'ay  goal  directed  (backward-chaining}  inferenclng  in  search 
of  a  value  for  the  variable  "remedy."  To  tne  user  it  appears  that 
the  the  first  step  toward  a  solution  comes  in  determining  which 
subsystem  is  the  source  of  the  anomaly.  Given  a  selection  of  the 
AVCS,  the  circumstances  under  which  the  anomaly  occurred  must  be 
determined.  This  narrowing  of  the  solution  path  by  circumstance 
allow*  NAVAiiE?  to  narrow  search.  If  the  anomaly  occurred  under 
normal  uperatlng  conditions,  then  NAVARES  must  again  narrow  the 
source  of  the  problem.  For  example,  after  AVCS  is  selected  the 
problem  may  be  relate^  to  a  "Loss  of  Earthw  (when  the  satellite 
loses  its  ability  to  maintain  its  attitude  in  space),  or  one  of 


four  other  areas  (If  the  n.se>'  cannot  specify  this  subgroup  as 
the  source  oi  the  problem,  NaVAkES  must  attempt  this  selection 
given  the  facts  available).  Under  each  of  the  five  AVCS  normal 
operations  subgroups,  may  be  many  possible  solution  paths  for 
NAVARES  to  follow.  The  system  may  also  terminate  pursuit  of  a 
particular  path  and  search  another  if  the  original  direction  does 
not  lead  to  any  solution. 

If  the  anomaly  had  occurred  under  other  than  normal  operating 
conditions,  NAVAIi!2S  would  pursue  a  solution  path  under  the 
appropriate  circumstance  (e.g.,  Delta-V  Maneuver,  Spin 
Stabilization,  or  Dual  Magnet  Momentum  Dump  (DMMD?  execution). 
Again,  each  circumstance  may  lead  to  one  of  a  number  of  solutions, 
but  in  this  case  NAVARES  would  not  attempt  to  reach  a  solution 
under  another  set  of  circumstances  if  the  original  selection  did 
not  lead  to  a  solution. 

NAVARES  allows  two  possible  circumstances  under  which  an  EPS 
anomaly  may  occur:  normal  operations  and  battery  reconditioning. 
Given  that  normal  operations  is  selected,  the  user  of  the  system 
may  again  narrow  the  set  of  possible  solution  paths  to  one  of  four 
subgroups.  Of  course,  as  with  the  AVer,  NAVARES  may  terminate 
pursuit  of  a  solution  a’ org  a  given  path  and  pursue  another  based 
on  the  facts  available  at  any  time. 
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Data  Management .  The  data  management  capabilities  of  Guru 
are  used  to  maintain  records  of  past  anomaly  report  titles  so 
that,  regardless  of  NAVARBS '  success  in  finding  a  solution  to  the 
problem  at  hand,  the  user  may  request  a  list  of  relevant  past 
reports.  These  reports  may  be  very  helpful  in  providing  the 
satellite  engineer  clues  to  the  source  of  an  anomaly. 

The  process  of  storing  and  retrieving  report  titles  is 
relatively  simple.  Each  report  is  listed  as  a  record  in  a  data 
base  table  with  fields  to  identify  the  circumstances  of  the 
anomaly  and  the  subgroup  which  was  involved.  At  the  end  of  an 
execution  of  the  prototype,  the  values  of  the  system’s  variables 
(the  facts  Known  about  the  satellites  status)  will  be  used  to 
retrieve  relevant  report  titles  from  the  data  base.  Reports  are 
retrieved  on  the  basis  of  satellite  number,  circumstance  of 
anomaly,  and  subgroup  to  which  the  anomaly  is  related  (e.g., 
battery.  Solar  Array,  etc.). 

User  Interface .  NAVARES  is  a  very  interactive  system.  The 
prototype's  knowledge  about  a  satellite's  current  health  comes 
entirely  from  user  input.  (See  Appe  idix  R  for  a  sample  session). 
The  user  is  first  queried  for  a  name,  date  and  SV  number  (SVN) . 
Next  the  user  is  presented  with  a  menu  from  which  he  must  select 
the  subsystem  he  suspects  to  be  the  source  of  the  problem. 

Based  on  this  selection,  NAVARES  will  execute  one  of  the 
three  more  general  rule  sets;  AVCS,  EPS  or  Unknown.  The  next  menu 
will  present  the  user  with  a  choice  of  circumstances  under  which 
the  anomaly  occurred.  These  choices  will  be  different  depending 
on  which  subsyste,.i  was  chosen.  With  the  circumstances  selected. 
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the  user  must  respond  to  specific  questions  about  satellite 
subsystem  and  component  status  and  the  current  operating 
environment.  If  the  anomaly  occurred  while  under  normal  operating 
conditions,  then  the  user  also  has  the  choice  of  forcing  NAVARES 
to  search  a  narrow  solution  path  or  a  broad  one.  He  does  this  by 
selecting  either  a  subgroup  related  to  tne  anomaly  (e.g..  Battery, 
Solar  Array,  etc.)  or  choosing  "unknown"  and  responding  to  the 
prototype's  queries.  The  traoe-off  here  is  between  time  of 
execution  and  the  thoroughness  of  the  search  for  a  solution.  It 
would  seldom  be  wise  to  narrow  the  solution  path  too  early  and 
risk  pruning  a  fruitful  bra.ich. 

Once  NAVARES  determines  that  it  has  found  a  solution 
(satisfied  the  goal),  or  cannot  find  a  solution  (cannot  find  a 
value  for  the  variable  "remedy"),  then  it  responds  by  displaying 
the  solution  to  the  user  or  explaining  that  the  user  has  exceeded 
the  limits  of  its  knowledge.  At  any  time  during  the  user's 
Interaction  *. ith  the  system  he  may  request  an  explanation  of  why 
NAVARES  is  requesting  information  about  a  particular  subject. 

This  explanation  is  displayed  in  a  window  at  the  bottom  of  the 
screen . 

The  final  menu  allows  the  user  to  display  the  final  report, 
print  the  final  report,  or  exit.  The  final  report  may,  or  may 
not,  include  a  list  of  relevant  past  anomaly  reports  based  on  the 
user's  Indicated  preference. 
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Output .  An  example  of  the  prototype's  output  is  shown  in 
Figure  6.  It  gives  an  assessment  of  the  satellites  malfunction 
(DISORDER)  and  a  suggested  solution  (REMEDY).  In  addition/ 
xelevant  past  reports  are  listed.  In  the  event  that  NAVARES  fails 
to  provide  a  solution  (DISORDER  and  REMEDY)  the  user  may  still 
request  a  display  or  hardcopy  of  relevant  past  reports. 


AME: 

t  Pam  Neal 


DATE : 

14  March  1988 


SVN: 

1 


ISORDER: 

It  is  possible  that  the  Solar  Array  Drive  went  to  hold  mode 
because  of  a  "bit  hit"  from  cosmic  radiation  or  some  other  cause. 
(See  DR  SCF  5111-78). 
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EMEDY: 


If  it  can  be  determined  that  one  Solar  Array  Drive  channel  is| 
more  susceptible  to  space  charge  than  the  ether,  then  switch  to 
the  less  vulnerable  channel.  Otherwise,  no  corrective  action  can 
suggested.  (See  DR  SCF  5111-78) 


Reports  by  SVN: 
TITLE 


DR  SCF  5111-21 
bR  SCF  5111-35 
R  SCF  5111-78 


(Reports  by  anomaly  type; 
TITLE 

bR  SCF  5111-78 


Figure  6.  Sample  NAVARES  Output 
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VII .  Evaluation 


Introduction 

Perhaps,  the  greatest  value  o£  any  Initial  prototype  is  in 
providing  a  "straw  man"  for  the  users  so  that  they  might  see  what 
they  like  and  do  not  like.  However,  before  NAVARES  was  given  to 
the  users  for  an  extensive  evaluation  a  more  formal  verification 
and  validation  process-  was  conducted  with  a  representative  of  the 
users  group.  In  this  context,  verification  is  the  process  of 
ensuring  that  the  code  works  as  intended.  Validation  is  the 
process  of  determining  how  accurately  NAVARES  reflects  the  real 
world.  Put  another  way,  verification  answers  the  question  "Am  I 
building  the  product  right?",  while  validation  answers  the 
question  "Am  I  building  the  right  product?"  (5:75)  This  chapter 
presents  the  verification  and  validation  process  and  a  critique  of 
Guru. 

Verification 

NAVARES'  knowledge  representation  is  more  complex  than  a 
collection  of  independent  solution  paths.  The  branches  of  the 
search  trees  are  entwined.  Thus,  it  would  be  an  overwhelming  task 
to  test  all  the  possible  solution  paths  exhaustively.  Instead, 
the  anomaly  case  reports  and  sections  of  the  00H  that  served  as 
sources  of  knowledge  were  used  to  verify  that  the  prototype  works 
as  intended. 
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Table  IX  shows  the  verification  test  matrix.  The  knowledge 
sources  are  listed  along  the  left  hand  side.  The  symptoms  or 
scenarios  presented  in  each  source  were  input  into  the  system  to 
se^  if  the  proper  solution  was  reached.  However,  NAVARES  allows  a 
user  to  approach  a  problem  from  several  directions.  He  may 
specify  AVCS,  EPS,  or  Unknown  as  the  effected  subsystem.  If  the 
anomaly  occurred  during  normal  operations,  then  the  user  may  also 
specify  a  subgroup  to  search  for  a  solution  or  he  may  choose 
unknown.  Moreover,  some  solutions  may  be  reached  through  a  number 
of  different  subgroups.  For  instance,  a  space  charge  anomaly  in 
'the  Solar  Array  Drive  may  cause  symptoms  that  indicate  Loss  of 
Earth,  Load  Shed,  and  Solar  Array  related  problems.  Accordingly, 
NAVARES  allows  the  user  to  reach  the  same  solution  by  choosing  any 
of  the  latter  three  possible  areas  or  by  choosing  "unknown.” 

For  verification  purposes,  six  possible  solution 
paths  were  specified: 

1.  AVCS  selected,  and  if  circumstances  were  normal 
operations,  subgroup  specified 

2.  AVCS  selected,  and  if  circumstances  were  normal 
operations,  no  subgroup  specified 

3.  EPS  selected,  and  if  the  circumstances  were  normal 
operations,  subgroup  specified 

4.  EPS  selected,  and  if  the  circumstances  were  normal 
operations,  no  subgroup  specified 

5.  Unknown  selected,  and  if  the  circumstances  were  normal 
operations,  subgroup  specified 


v  6.  Unknown  selected/  and  if  the  circumstances  were  normal 
operations,  no  narrow  area  or  component  group  specified 


_ C&§fi§ _ 

I  DR  SCF  5111-21 _ 

I  DR  SCF  5111-35 _ 

i  DR  SCF  5111-78 _ 

!  DR  SCF  5112-21 _ 

I  DR  SCF  5112-31 _ 

i  DR  SCF  5112-37 _ 

I  DR  SCF  5112-38 _ 

I  MCS-9721-02 _ 

I  MCS-9794-01 _ 

I  OOH  3.7.9 _ 

1  OOH  3.7.10 _ 

I  OOH  3.7.11 _ 

1  OOH  3. 8. 2. 3. 7 _ 

I  OOH  3. 8. 2 .3-1  _ 

I  OOH  3. 8. 2. 3- 2 _ 

I  OOH  3. 8. 2. 3-3 _ 

I  OOH  3. 8, 2. 3-4 _ 

I  OOH  3. 8. 2. 3-6 _ 

I  OOH  3. 8. 2, 3-7 _ 

l  iK>r>  j  .  o  .  ^  .  j  -o _ 

\  OOH  3.9.2.3-20  (partial) 


SOLUTION  PATHS 


XX 


XI 


XX 


LX 


XXX 


XX 


XX 


XX 


XX 


XX 


XX 


XX 


XX 


XX 


XX 


1  V  I  V  I  V  1 

1  W  A.  ■  ■  «  •> 


V  I 


xxxxxxxxx 


Table  IX.  Verification  Test  Matrix 

As  each  case  was  run,  the  data  base  search  for  past  anomaly 
reports  was  also  checked  to  ensure  that  the  appropriate  report 
titles  were  retrieved  by  SVN  snd  by  anomaly. 

The  verification  process  revealed  no  major  problems  with  the 
prototype's  performance.  The  majority  of  problems  encountered 
were  related  to  the  orderly  presentation  of  information  to  the 
user.  All  the  glitches  were  corrected  on  the  spot.  NAVARES  works 
as  intended. 
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Validation 

There  were  four  important  questions  that  had  to  be  considered 
during  the  validation  phase.  First,  were  the  knowledge  sources 
valid?  Second,  were  the  knowledge  sources  correctly  interpreted 
and  correctly  represented  in  the  knowledge  base?  Third,  how  much 
of  the  necessary  knowledge  about  NAVSTAR  AVCS  and  EPS  anomalies 
had  been  included  in  NAVARES'  knowledge  base?  Fourth,  how  would 
the  prototype  perform  against  unanticipated  anomalies,  those  not 
already  built  into  the  knowledge  base?  To  answer  these  questions, 
NAVARES  was  presented  with  three  scenarios  used  by  the  2  SCS 
Standardization  and  Evaluation  branch  to  evaluate  the  squadron's 
SEOs  and  the  system  was  reviewed  by  a  representative  from  the 
engineering  branch  of  the  2  SCS  performing  temporary  duty  at  AFIT. 


val idi ty  of  Sources .  The  first 
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sources  valid?",  must  be  answered  in  the  affirmative.  However, 
many  of  the  case  reports  were  written  by  technicians  at  the 
Satellite  Control  Facility  before  Satellite  Control  Authority  was 
passed  to  the  MCS  and  contain  slightly  different  terminology  than 
that  in  use  at  the  2  SCS.  The  OOH  also  contains  some  differences 
in  component  names  and  mnemonics.  These  differences  were  limited 
and  do  not  affect  the  validity  of  the  system. 

Validity  of  Interpretation .  The  second  question,  "Were  the 
knowledge  sources  correctly  interpreted  and  correctly  represented 
in  the  knowledge  base?",  may  also  be  answered  in  the  affirmative, 
but  with  exception.  This  portion  of  the  validation  process 
involved  a  review  by  the  visiting  engineer  and  presenting  NAVARES 
with  the  three  anomaly  scenarios.  The  2  SCS  engineer  did  not 
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participate  in  an  exhaustive  evaluation  o£  NAVARES *  knowledge,  nor 
was  this  particular  engineer  the  most  "expert.”  However,  he  has 
functioned  as  a  qualified  SEO  and  could  comment  intelligently  on 
the  structure  and  logic  of  the  system. 

The  engineer  felt  chat  the  structure  and  logic  of  NAVARES  was 
valid  with  only  minor  discrepancies.  The  order  in  which  NAVARES 
queried  the  user  for  information  about  Loss  of  Earth,  Load  Shed, 
and  Solar  Array  problems  did  not  reflect  the  priorities  and 
concerns  of  a  satellite  engineer  presented  with  the  same 
circumstances.  The  system  was  modified  so  that  it  will  always 
attempt  to  solve  Loss  of  Earth  problems  first,  before  attending  to 
less  critical  areas.  While  the  visiting  engineer  was  pleased  with 
the  validity  of  the  system  this  cannot  be  construed  as  a  final 
judgement  of  the  systems  validity.  This  judgement  must  come  from 
the  SEs  who  are  personally  responsible  for  the  AVCS  and  EPS. 

Beyond  this  informal  evaluation,  the  engineer  supplied  three 
anomaly  scenarios  used  to  evaluate  SEOs  before  they  may  be 
considered  "qualified"  for  duty.  These  three  scenarios  which 
pertain  only  to  the  AVCS  AND  EPS  were: 

Scenario  1:  Loss  of  Earth  without  Load  Shed  2  occurrence 
Scenario  2:  Excessive  discharge  during  Batter s 

Reconditioning/Failure  to  auto-terminate 
Scenario  3:  Cosmic  radiation  caused  bit  change  in  Magnet 
Control  Electronics 

NAVARES  correctly  solved  scenarios  2  and  3,  but  could  not  reach 
any  conclusions  for  scenario  1,  Scenario  2  is  covered  in  a 
portion  of  the  OOH  that  was  represented  in  NAVARES'  knowledge 
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base,  and  scenario  3  is  covered  by  a  past  anomaly  report  that  was 
also  represented  in  NAVARES'  knowledge  base.  As  for  scenario  1, 
NAVARES'  knowledge  about  Loss  of  Earth  was  too  limited.  Loss  of 
Earth  may  occur  as  a  result  of  an  EPS  failure  (e.g,,  Solar  Array 
Drive)  that  led  to  Load  Shed  2.  Load  Shed  2  shuts  down  the  AVCS, 
the  subsystem  that  maintains  the  SV's  attitude.  NAVARES  could 
handle  such  a  scenario.  But,  Loss  of  Earth  may  also  occur  without 
an  EPS  failure  or  Load  Shed  2.  It  may  result  from  an  AVCS 
anomaly.  It  was  this  latter  scenario  that  was  not  accounted  for 
in  the  knowledge  base.  This  deficiency  hrs  been  corrected. 

Amount  of  Knowledge .  The  third  question,  "How  much  knowledge 
is  included  in  the  knowledge  base?",  is  answered  subjectively. 
Since  there  are  hundreds  of  past  anomaly  reports  for  NAVSTARs  and 
myriad  possible  problems  that  might  arise  there  is  no  doubt  that 
NAVARES  knowledge  ahout  AVCS  and  EPS  anomalies  is  incomplete.  The 
systems  performance  with  the  test  cases  proved  this  point.  But, 
within  the  range  of  possible  anomalies,  there  are  those  which  will 
occur  more  often.  Figure  7  shows  a  plot  with  performance  on  the 
vertical  a>:is  and  knowledge  along  the  horizontal.  This  curve  is 
not  based  on  scientific  analysis,  but  is  meant  to  illustrate  the 
idea  that  performance  (the  percentage  of  anomalies  successfully 
resolved)  increases  rapidly  if  knowledge  of  common  anomalies  is 
incorporated.  The  slope  then  decreases  as  knowledge  of  less 
common  problems  is  incorporated.  Finally,  the  curve  becomes 
asymptotic  with  the  perfect  performance  line  reflecting  the  fact 
that  the  range  of  possible  anomalies  is  seemingly  infinite.  Some 
may  never  be  successfully  resolved. 
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NAVARET)  Includes  nearly  200  unique  rules  (some  are  duplicated 
-in  different  rule  sets  so  the  total  number  of  ?.ules  is  higher), 
but  about  two  thirds  pertain  to  the.  EPS.  Therefore,  the  EPS  is 
shown  being  further  along  the  curve  in  Figure  7.  It  may  be  closer 
to  point  "B"  than  the  AVCS .  While  the  amount  of  knowledge  in  the 
system  is  limited,  it  provides  a  very  strong  foundation  for 
further  development.  More  rules  would  move  NAVARES  into  the 
region  between  MB"  and  "C",  but  rules  will  probably  not  get  the 
system  past  "C.*-  This  may  be  achieved  using  the  model-based 
approach . 

Unanticipated  Anomal ies .  The  fourth  question,  "How  would  the 
prototype  perform  against  unanticipated  anomalies?1',  is  important 
even  though  NAVARES  is  an  initial  prototype.  The  way  NAVARES 
handled  the  first  scenario  indicates  that  it  performs  well  -  it 
does  not  mislead  the  user.  When  presented  with  a  set  of 
circumstances  that  were  outside  the  limits  of  its  knowledge,  it 
simply  told  the  user  that  he  had  exceeded  the  limits  of  the 
system's  knowledge  and  provided  a  list  of  relevant  past  reports. 

Of  course,  the  potential  exists  for  NAVARES  to  recognize  a 
few  symptoms  of  an  anomaly  and  make  a  hasty  conclusion.  Such  a 
case  has  not  been  seen  yet,  but  may  arise  as  development 
progresses.  One  way  to  decrease  the  potential  for  damage  is  tc 
modify  the  system  so  that  it  presents  multiple  solutions  for 
consideration  by  the  user. 
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1  Tool  Cg  1  citjue 

Guru  proveo  to  be  a  good  choice  of  software  for  this  project. 
While  it  does  nave  some  disadvantages  these  are  outweighed  by  its 
advantages.  It  must  rate  as  one  of  the  most  ccpable  expert  system 
building  tools  available  for  PC  compatible  microcomputers. 

Disadvantages .  There  are  three  specific  disadvantages. 

First,  Guru  does  rot  allow  variable  names  longer  than  eight 
characters.  This  seemingly  trivial  limitation  may  present  the 
greatest  stumbling  block  to  maintainability.  Cryptic  varlablc 
names  were  created  which  will  serve  only  to  cenf  ,se  future 
developers.  Second,  Guru's  advertised  spreadsheet  capabilities 
are  very  limited.  In  fact,  these  spreadsheets  are  so  limited  in 
their  calculation  capabilities  that  they  might  more  correctly  be 
called  data  tables. 

The  third,  and  most  important,  disadvantage  was  Guru’s  memory 
management.  Early  in  NAVARES®  development,  the  user  was  allowed 
to  remain  within  tne  Guru  environment  and  repeatedly  execute  the 
program.  However,  with  every  run  cf  the  program  lea;'  and  less  RAM 
vas  available,  and,  eventually,  the  program  would  not  execute 
properly.  Curu  includes  a  "release"  command  which  allegedly 
clears  RAM  that  may  have  been  used  for  storing  variable  values, 
arrays,  etc.  Apparently,  this  command  does  not  function  properly. 
The  software  producers  claim  that,  if  used  co.  rectly  (taking  into 
account  Guru's  last-in -£ irst~out  memory  management ) ,  the  "release" 
command  should  clear  the  HAM,  This  developer  and  tvc  other  Guru 
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users  spent  a  great  deal  of  effort  attempting  to  make  the 
"release"  work  properly  with  no  success.  This  limitation  is  the 
reason  why  a  user  is  exited  from  the  Guru  environment  when  he 
exits  NAVARES. 

Advantages .  Guru  has  many  positive  attributes.  Perhaps, 
the  greatest  of  these  is  the  control  and  flexibility  afforded  the 
developer  by  the  Guru  procedural  language.  Procedural  code  may  be 
executed  anywhere  within  a  rule  set  or  control  the  execution  of 
rule  sets.  This  code  includes  enough  constructs  to  be  capable  of 
fairly  complex  applications  and  has  relatively  simple  syntax. 

Control  ano  flexibility  are  also  increased  through  the  many 
adjustments  available  for  modifying  the  infereneing  process.  Guru 
gives  the  developer  control  oi  the  finest  details  of  inferencing 
so  that  the  system  may  be  well  tailored  to  a  particular 
application* 

With  respect  to  the  user  interface,  control  and  flexibility 
are  again  the  key  points.  Many  microcomputer  based  expert  system 
tools  force  the  developer  into  a  rigid  user  interface.  The 
visiting  engineer  who  reviewed  the  system  remarked  that  when 
interacting  with  IJAVARES  it  war  not  obvious  that  he  was  running  an 
expert  system  shell.  This  is  a  great  compliment  and  Guru  deserves 
the  credit.  It.  was  even  possible  to  create  subsystem  block 
diagrams  and  an  illustration  of  a  NAVSTAR  satellite  for  display  to 
the  user.  Guru  also  includes  functions  to  create  menus  which  add 
to  the  friendliness  of  the  system. 
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For  the  developer ,  Guru  provides  o  menu  driven  interface  to 
perform  virtually  any  task  from  creating  a  rule  set  to  editing  a 
data  base  table.  This  is  a  great  advantage  for  the  novice,  but 
after  a  few  days  one  nay  choose  to  change  development  environments 
to  the  Guru  natural  language  interface  or  command  prompt. 

Overall,  Guru  was  a  very  good  choice.  It  has  a  broad  range 
of  capabilities  and  generally  performs  as  advertised.  It  may  take 
longer  to  learn  how  to  use  than  other  microcomputer  based  too.s, 
but  the  added  flexibility  and  control  available  are  the  returns 
payed  on  the  extra  time  invested. 
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VIII.  Conclusions  and  Recommendat 1 ons 


This  chapter  presents  a  final  review  of  the  research.  First, 
there  is  a  brief  synopsis.  Then  conclusions  and  recommendations 
are  presented. 

Synopsis 

The  goal  of  this  thesis  was  to  demonstrate  the  applicability  of  AI 
to  satellite  command  and  control,  specifically,  by  developing  a 
prototype  expert  system  for  NAVSTAR  anomaly  resolution.  It  was 
proposed  that,  first,  an  expert  system  could  offer  a  means  of 
maintaining  corporate  knowledge  in  the  all  “Blue  Suit"  satellite 
engineering  branch  of  the  2  SCF.  The  system  could  assist  the 
relatively  inexperienced  satellite  engineers  in  maintaining  the 
operational  status  of  the  GPS  satellites.  Second,  the  system 
could  take  advantage  of  the  "economies  of  scale"  offered  by  using 
the  NAVSTAR  consteJ lat ion  as  the  target  system. 

A  rule-based  prototype  was  built  on  a  microcomputer  using  the 
Guru  expert  system  building  tool.  The  system  consists  of  seven 
rule  sets,  three  procedural  code  files,  and  one  data  base  table. 

A  subjective  and  objective  evaluation  process  has  s  own  that 
NAVARES  successfully  diagnoses  many  AVCS  and  EPS  anomalies.  The 
systeM  is  by  no  means  ready  to  be  used  operationally.  Much  more 
work  needs  to  be  done  before  that  is  possible.  At  this  point,  the 
prototype  should  be  used  as  a  point  of  departure  for  the  users, 
the  satellite  engineers,  to  define  their  requirements  and 
determine  what  role  AI  will  play  in  their  decision  support 
systems . 
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Cone 1 us  ions 

There  are  four  conclusions  drawn  from  this  research  effort. 
First,  the  evaluation  process  has  shown  NAVARES  to  be  a  successful 
prototype.  If  its  knowledge  is  expanded,  it  can  be  a  useful 
decision  aid  in  resolving  NAVSTAR  anomalies.  One  of  the  greatest 
challenges  during  the  development  process  was  determining  the 
structure  with  which  to  organize  the  knowledge  about  SV  anomalies. 
This  structure  appears  valid  and  provides  a  firm  foundation  to 
build  upon.  There  will  undoubtedly  be  modifications  required 
based  or,  the  users'  extensive  evaluation. 

Second,  knowledge  engineering  was  difficult  in  such  a 
technical  and  specialized  domain.  To  take  NAVARES  further  toward 
an  operational  system  will  require  very  close  interaction  between 
the  satellite  engineers  (the  experts),  and  the  developer.  Having 
a  patient  and  willing  expert,  and  a  developer  already  well  versed 
in  the  technical  details  of  NAVSTAR  operations  and  the  SV's 
design,  will  dramatically  increase  the  likelihood  of  success  in 
developing  an  operational  system. 

Third,  although  Guru  is  not  without  its  disadvantages,  it  may 
very  well  be  the  best  choice  of  software  for  further  development. 
The  cryptic  nature  of  its  variable  names  will  offer  a  challenge  to 
system  maintenance.  The  spreadsheet  limitations  do  not  pose  an 
insurmountable  problem  since  Guru  also  interfaces  with  Lotus  123 
which  is  already  available  to  the  users.  The  system  also  poses  no 
immediate  limitations  to  growth  as  Guru  allows  systems  of 
thousands  of  rules  and  the  partitioning  of  knowledge  into  many 
interacting  rule  sets.  Perhaps,  the  only  worrisome  limitation  is 
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the  memory  management  problem  encountered.  For  now,  it  appears 
that  exiting  to  the  operating  system  after  every  run  will  prevent 
any  difficulties. 

Fourth,  this  research  centered  on  the  application  of  AI  to 
the  anomaly  resolution  process,  but  it  has  become  clear  that 
another  perspective  might  prove  even  more  useful  to  the  satellite 
engineers  of  the  2  SCS.  This  perspective  is  to  examine  their 
needs  in  terms  of  a  decision  support  system  (DSS)  in  which  an 
expert  system,  such  as  NAVARES,  might  play  a  central  role  (21). 

As  Figure  8  illustrates,  the  concept  of  a  DSS  consisting  of  three 
parts,  a  model,  data,  and  the  man  machine  interface,  would  have  an 
expert  system  as  the  model,  and  telemetry  and  other  status 
information  as  the  data. 

fiCU  VMmicuum  u  a  vug 

The  most  important  recommendation  resulting  from  this 
research  is  that  the  users  seriously  examine  their  needs  for 
decision  support  using  the  thesis  prototype  to  help  define  their 
requirements.  NAVARES  is  not  a  solution,  but  demonstrates  a 
technology  that  has  the  potential  to  increase  operational 
effectiveness . 

There  are  four  specific  recommendations  for  improvements  to 
the  prototype.  First,  NAVARES'  usefulness  would  be  increased  by 
an  order  of  magnitude  if  it  gave  multiple  solutions  with  varying 
degrees  of  confidence  rather  than  single  solutions  as  it  does  now. 
Guru  allows  for  such  an  extension,  and  this  should  be  the  first 
step  toward  an  operational  system. 
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.  Satellite  Engineers'  Decision  Support  System 


Second,  the  system  should  be  expanded  to  include  more 
knowledge  about  the  AVCS  and  EPS ,  And,  when  the  AVCS  and  EPS  are 
up  to  speed,  the  NAV  and  NDS  should  be  added  -  These  additions 
would  give  NAVARES  the  capability  to  handle  most  of  the  important 
-potential  SV  anomalies. 

Third,  Guru  has  a  limited  capability  for  displaying  diagrams 
that  may  be  very  useful  in  improving  the  user  interface. 

Subsystem  or  component  block  diagrams  could  be  displayed  with 
flags  to  indicate  the  effected  areas  or  to  provide  background 
information  to  the  user. 

Fourth,  in  the  long  run  an  anomaly  resolution  expert  system 
will  require  access  to  increasing  amounts  of  data.  It  will  become 
increasingly  cumbersome  and  time  consuming  for  the  user  to  supply 
this  information  at  the  keyboard.  Thus,  as  the  system  moves 
toward  operational  status  it  should  be  interfaced  with  the  data 
files  containing  telemetry,  status  (configuration),  and  trend 
analysis  information 

Summary 

NAVARES  demonstrates  that  an  expert  system  can  successfully 
contribuze  to  a  portion  of  the  satellite  command  and  control 
process.  It  is  now  up  to  the  users  to  determine  if  this  approach 
should  be  pursued  in  support  of  their  operations. 
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Appendix  A:  llaintenance  Guide 


Th?  information  presented  in  this  appendix  should  be  useful 
in  performing  system  maintenance.  This  appendix  is  not 
recommended  reading  tor  the  casual  user,  but  is  recommended 
reading  for  future  developers  of  NAVARES.  A  copy  of  the  computer 
code  can  be  obtained  by  contacting  the  Department  of  Operational 
Sciences,  Air  Force  Institute  of  Technology,  Wr ight-Patter son  AFB, 
OH,  45433,  (513)  255-3362/2549. 

Files  and  Their  Funct i ons 

This  section  describes  the  files  that  make  up  NAVARES  and 
their  functions.  Within  Guru  there  are  several  different  types  of 
files.  NAVARES  uses  three  cf  these  file  types. 

1.  ".ipf"  -  Perform  files  -  files  that  contain  Guru  commands 
(procedural  code),  but  no  rules  or  tables 

2.  ".rss"  -  Rules  sets  -  structured  Guru  files  for  executing 
groups  of  rules  which  may  also  contain  procedural  code 

3.  ".itb"  -  Data  tables  -  data  base  tables 

There  are  also  three  '’.bat”  or  batch  files  accompanying  NAVARES, 
These  files  contain  MSDOS  commands . 

gps . ipf .  This  file  initializes  NAVARES.  It  declares  all  the 
global  variables,  arrays  and  forms  used  during  execution.  It  also 
presents  the  first  few  screens  to  the  user.  When  the  user  chooses 
one  of  the  three  subsystems  form  the  first  menu  gps. ipf  executes 
the  appropriate  rule  set. 
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avcs . rss ,  The  AVCS  rule  set  contains  rules  covering  many 
AVCS  problems.  It  is  called  by  gps.ipf  if  the  user  chooses  "AVCS" 
as  the  effected  subsystem.  If  "Yaw  related"  or  "Unknown"  is 
selected,  then  avcs. rss  will  call  yaw. rss.  The  rule  set 
"avcs. rss"  also  calls  smallkbs . ipf  and  search. ipf  which  will  be 
described  later. 

eps . rss .  The  EPS  rule  set  contains  rules  covering  many  EPS 
problems.  It  is  executed  by  gps.ipf  if  the  user  chooses  "EPS”  as 
the  effected  subsystem.  If  "Unknown"  is  selected  as  the  subgroup 
under  Normal  Ops,  then  eps. rss  will  call  sa.rss.  Is. rss  and 
bat. rss.  If  "Solar  Array,"  "Load  Shed,"  or  "Battery"  is  selected, 
eps. rss  will  call  either  sa.rss.  Is. rss  or  bat. rss,  respectively. 
This  rule  set  also  calls  smallkbs. ipf  and  search. ipf. 

unk , rss .  The  Unknown  rule  set  contains  rules  covering  many 
AVCS  and  EPS  problems.  There  is  some  duplication  of  rules  from 
the  AVCS  and  EPS,  but  this  duplication  is  minimized  by  calling  the 
same  yaw. rss,  sa.rss.  Is. rss  and  bat. rss  rul*  sets  that  are  called 
by  the  AVCS  and  EPS  rule  sets.  The  Unknown  rule  set  also  calls 
smallkbs. ipf  and  search. ipf.  It  is  executed  when  the  user 
selects  "Unknown"  from  the  first  menu  which  asks  the  user  to 
identify  the  effected  subsystem. 

sa.rss .  This  rule  set  contains  rules  covering  Solar  Array 
related  problems.  It  may  be  called  by  either  the  EPS  or  the 
Unknown  rule  set.  The  perform  file  "smallkbs . ipf "  is  actually 
called  by  the  higher  level  rule  sets  and,  in  turn,  executes 
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sa.rss.  The  Solar  Array  rule  set  does  not  call  any  other  files 
itself.  It  will  return  to  execution  of  the  EPS  or  Unknown  rule 
set  depending  on  which  was  the  "caller." 

ls.rss .  This  rule  set  contains  rules  covering  Load  Shed 
^related  problems.  It  may  be  called  by  either  the  EPS  of  Unknown 
rule  set.  The  perform  file  "smallkbs . ipf "  is  actually  called  by 
the  higher  level  rule  sets  and,  in  turn,  executes  ls.rss.  The 
Load  Shed  rule  set  does  not  call  any  other  files  itself.  It  will 
return  to  execution  of  the  EPS  or  Unknown  rule  set  depending  on 
which  was  the  "caller." 

bat ,rss .  This  rule  set  contains  rules  covering  many  Battery 
related  problems.  It  may  be  called  by  either  the  EPS  or  Unknown 
.rule  set.  The  perform  file  "smallkbs . ipf "  is  actually  called  by 
the  higher  level  rule  sets  and,  in  turn,  executes  bat.rss.  The 
Battery  rule  set  does  not  call  any  other  files  itself.  It  will 
return  execution  to  the  EPS  or  Unknown  rule  set  depending  on  which 
was  the  "caller." 

yaw. rss .  This  rule  set  contains  rules  covering  Yaw  related 
problems.  It  may  be  called  by  either  the  AVCS  or  Unknown  rule 
set.  The  perform  file  "smallkbs . ipf "  is  actually  called  by  the 
higher  level  rule  sets  and,  in  turn,  executes  yaw. rss.  The  Yaw 
rule  set  does  not  call  any  other  files.  It  will  return  execution 
to  the  AVCS  or  Unknown  rule  sets  depending  on  which  wars  the 
"caller . " 

smallkbs . ipf .  This  procedural  code  file  may  be  called  by 
avcs.rss,  eps.rss  oi  unk.rss.  It  contains  conditional  statements 
that  will  execute  one  or  more  of  the  four  lower  level  rule  sets 
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(i.e.,  sa.rss,  ls.rss,  bat.rss,  and  yaw.r»s).  Upon  completion  of 
this  perform  file,  the  calling  rule  set  (avcs.rss,  eps.rss,  or 
urk.rss)  continues  execution  at  the  point  following  its  call  to 
smallkbs . ipf . 

search . jpf ♦  This  perform  file  may  be  executed  by  either  the 
AVCS,  EPS,  or  Unknown  rule  sets.  The  file  "search . ipf "  is 
executed  in  the  completion  conditions  of  the  rule  sets  (executed 
after  NAVARES  has  found  a  solution  or  has  determined  that  it 
cannot  find  a  solution).  It  contains  procedural  code  for 
retrieving  past  anomaly  import  titles  from  the  past  report  data 
table  (pr.itb)  based  on  SVN,  circumstance  of  the  anomaly  (KAVARES 
variable  "event"),  and  anomaly  type  (NAVARES  variable  "normvent") 
if  circumstances  were  normal  operations. 

pr . itb .  This  da  table  contains  nine  fields.  The  first 
field  contains  the  past  report  title  which  is  retrieved  for  the 
user  based  on  the  values  of  the  remaining  eight  fields. 

Field  Name  Description 

TITLE  Past  report  title 

SUBSYS  Effected  subsystem 

SATNUM  Satellite  vehicle  number 

UNKCOND  Anomaly  Circumstances  (unk.rss  run) 

UNKNORM  Anomaly  type  or  subgroup  (unk.rss  run) 

AVCSCOND  Anomaly  Circumstances  (avcs.rss  run) 

AVCSNORM  Anomaly  type  or  subgroup  (avcs.rss  run) 

EPSCOND  Anomaly  Circumstances  (eps.rss  run) 

EPSNORM  Anomaly  type  or  subgroup  (eps.rss  run) 
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Retrieval  of  reports  by  SVN  is  straightforward,  but  retrieval  by 
the  remaining  fields  is  lass  obvious.  (The  field  "5UBSYS"  is  not 
actually  used  for  report  retrieval,  but  is  included  as  a  "hook" 
that  might  be  used  in  future  development  to  retrieve  reports  by 
effected  subsystem.)  When  the  user  chooses  the  circumstances  of 
the  anomaly  (e.g..  Normal  Ops,  Delta-V,  etc.  )  the  variable  "event” 
is  set  equal  to  the  number  of  the  choice  on  the  menu.  This 
variable  ("event”)  is  matched  against  UNKCOND,  AVCSCOND  or  EPSCOND 
to  retrieve  reports  depending  on  which  subsystem  rule  set  was 
executed.  Each  rule  set  has  a  "XXXCOND"  field  since  the  menus  are 
different  for  each  one.  The  UNKNORM,  AVCSNORM,  and  EPSNORM  fields 
are  matched  against  the  NAVARES  variable  "normvent”  for  report 
title  retrieval.  When  „he  user  chooses  a  subgroup  under  Normal 
Ops  the  variable  "normvent”  is  assigned  the  number  of  the  choice 
cn  the  menu.  Since  the  menus  are  different  in  the  three  subsystem 
rule  sets  there  are  three  "XXXNOP’J”  fields  in  pr.itb. 

prsvn.itb.  prevent,  itb.  pi.norm.  itb.  These  three  data  tables 
do  not  exist  prior  to  the  execution  of  NAVARES.  They  are  created 
by  the  search. ipf  perform  file  upon  its  execution.  They  will  hold 
the  past  report  titles  retrieved  cased  on  the  values  of  the 
/anables  ”svn,”  "event,"  and  "normvent,"  respectively.  If  there 
are  no  reports  found  based  on  a  search,  then  the  corresponding 
table  will  not  be  created.  For  example,  it  the  user  . ists  "7"  as 
the  SVN  and  pr.itb  has  no  reports  for  SATNUM=7,  then  the  tabla 
"prsvn.itb”  will  net  be  created.  With  each  execution  of  NAVARES 
these  three  data  tables  are  delated  then  re-created. 
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epsdia.ipf,  bccdla.iof.  batdja.jpf.  These  three  perform 


files  actually  contain  the  definitions  of  component  diagrams  of 
the  EPS.  They  are  executed  in  demonstration  cases  to  visually 
indicate  the  malfunctioning  component  to  the  user. 

startup . jpf .  This  perform  file  is  immediately  executed  upon 
entering  the  Guru  environment.  With  NAVARES,  gps.ipf  is  copied 
into  this  file  so  that  the  user  does  not  have  to  learn  any  Guru 
commands  to  execute  the  program.  He  simply  types  "ens"  at  the 
MSDOS  prompt  and  NAVARES  is  executed. 

ens . bat  This  file  contains  the  command  that  must  be  typed  at 
the  MSD03  prompt  to  execute  Guru  ("guru  -g").  Again,  its  function 
is  to  keep  the  user  from  having  to  learn  Guru  commands. 

in. bat,  out. bat.  These  "batch"  files  contain  MSDOS  commands 
that  will  transfer  all  the  files  necessary  for  NAVARES  execution 
(not  including  the  Guru  software  itself)  to  and  from  the  user's 
h<*rd  disk  (assumes  floppy  drive  labeled  "A"  and  hard  disk  labeled 
"C")  . 

Key  Var iables 

This  section  describes  the  key  variables  used  in  NAVARES. 
"event" .  This  numeric  variable  is  used  in  each  of  the  three 
subsystem  rule  sets:  avcs.rss,  aps.rss,  and  unk.rss.  It  is  the 
first  variable  that  assumes  a  new  value  in  an  execution  of  the 
program,  and  its  value  is  a  number  which  corresponds  to  the  users 
choice  of  circumstances  under  which  the  anomaly  occurred  (the 
number  from  the  circumstance  menu).  For  instance,  in  the  EPS  rule 
set  event  may  equal  "1"  or  "2"  since  the  user  may  only  choose 
"Normal  Ops"  or  Battery  Reconditioning."  In  the  Unknown  rule  set. 
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event  may  equal  a  nu.iber  from  one  through  five.  Cnee  the 
circumstances  are  known  (event=j>,  then  the  possible  solution 
path  can  be  narrowed.  For  example,  it  eve,it  =  2  in  the  EPS  rule 
set,  then  only  rules  pertaining  tc  these  conditions  {Battery 
Reconditioning)  will  be  considered.  This  shortens  execution  time 
and  prevents  inappropriate  queries. 

ask i  (i  -  1,  2.  3.  4 .  S )  .  When  a  value  is  obtained  tor  the 
variable  "event”  there  is  a  corresponding  value  set  for  the 
variable  "aski."  It  Normal  <  ps  is  selected,  event  is  set  eguc.l  to 
"1"  and  "askl"  is  set  to  "true.”  If  e'»cnt  were  set  eon'di  to  "2," 
then  ”ask2'’  is  set  to  'true  "  This  variable  simply  allows  for  a 

logical  separation  of  tul^s  s<-  tnat  the  system  will  never  attempt 

to  ask  tr.e  user  tor  inf  orr :-ti  -.n  th^t  is  not  relevant  tc  the 
selected  circumstances  under  which  the  anomaly  occurred .  For 
cases  where  i  =  2,  3,  4,  or  5,  "aski"  Is  the  last  variable  used  to 

logi<~=iliy  separate  rules.  The  remaining  rules  seek  evidence  of  an 

an*.  y.  But,  for  i  -  1,  the  Normal  Ops  case,  mere  logical 
on  occurs. 

s.  'mvent" .  Assuming  that  the  user  has  selected  'Normal  Ops" 
as  the  circumstance  under  which  the  anumaly  occurred,  NAVARES 
attempts  to  narrow  the  possible  solution  paths  ever  further.  The 
user  is  asked  to  choose  one  of  up  to  ten  subgroups  iavcs.rss  has 
six  subgroups,  eps.rss  has  five)  including  the  option  "Unknown." 
The  variable  "normv;  nt"  is  set  equal  tc  the  number  corresponding 
to  the  user's  selection  of  subgroup  from  the  menu.  If  the  user 
selects  any  subgroup  other  than  Unbr.own,  then  NAVARES  will  pursue 
solution  paths  which  pertain  only  uc  that  subgioup  and  disregard 


other  possibilities.  If  the  user  chooses  Unknown,  then  all 
subgroups  are  Included  in  the  search  for  a  solution.  This  process 
of  narrowing  the  search  is  affected  by  the  next  variable. 

wchk‘Z22" .  Just  as  aski  li  =  1,  2,  3,  4,  5)  was  used  to 
log.ical.ly  separate  rules  that  pertained  to  different 
circumstances,  chkzzz  is  used  to  logically  separate  rules  that 
pertain  tc  different  subgroups.  For  instance,  in  unk.rss,  if  the 
subgroup  "Load  Shed"  is  selected  (normvent=l ) ,  then  the  variable 
"cnkldshd"  is  set  to  "true."  On  the  other  hand,  if  the  user 
selects  "Unknown,"  then  all  the  "chkzzz"  variables  are  set  to 
"true"  and  to AVAR ES  considers  all  subgroups  in  searching  for  a 
solutir.n.  The  subgroups  and  their  corresponding  "chkzzz" 
variables  are  as  follows; 

1_  Load  Shed  -  chkldshd 

2.  Solar  Array  -  chksac 

3.  Battery  -  chkbak 

4.  Shunt  Dies.  -  chksdv 

5.  Loss  of  Earth  -  chksafe 

6.  Magnet  -  chkrmagl 

7.  Reaction  Wheel  -  chkwheel 

8.  Momentum  Dump  -  chkcnid 

9.  Yriv  -  chkclips 

The  remaining  NAVARES  variables  are  defined  in  the  gps.ipf 
perforin  file.  The  future  developer  should  also  keep  in  mind  the 
fact  that  NAVARES  is  backward-chaining  in  search  of  a  value  for 
the  variable  "remedy."  While  it  is  simpler  to  think  in  terms  of 
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narrowing  the  search  from  circumstance  to  subgroup,  subgroup  to 
evidence,  evidence  to  disorder,  and  disorder  to  remedy,  the  system 
is  actually  searching  in  the  opposite  direction. 

Past  Report  Table  Updating 

As  discussed  earlier,  the  search. ipf  perform  file  is  executed 
at  the  end  of  the  Unknown,  AVCS,  and  EPS  rule  sets.  This  program 
retrieves  past  report  titles  from  pr . itb  based  on  the  values  of 
the  variables  "svn,"  "event,"  and  "normvent."  The  values  for 
event  and  ncrmvent  will  vary  between  the  three  subsystem  rule  sets 
so  there  are  corresponding  fields  in  pr.itb  for  each  rule  set  (see 
discussion  of  pr.itb  in  "Files  and  Their  Functions").  If 
"Unknown"  was  chosen  as  the  subgroup,  then  procedural  code  is 
executed  at  the  end  of  each  subsystem  rule  set  that  assigns  a  new 
value  to  not  invent  based  on  the  information  presented  to  NAVARES 
during  execution.  This  new  value  assigned  to  normvent  will 
correspond  to  a  particular  subgroup  identified  as  the  source  of 
the  anomaly.  This  value  of  normvent  will  then  be  used  by 
search. ipf  to  match  against  the  fields  "UNKNORM,"  "AVCSNORH, "  or 
"EPSNORM"  depending  on  which  rule  set  had  been  executed. 

To  update  or  expand  pr.itb  a  new  record  in  the  table  should 
be  created  with  appropriate  values  in  each  field.  For  instance,  a 
new  report  for  SVN  6  should  be  entered  with  the  title  under  the 
'•TITLE"  field  and  a  "6"  in  the  "SATNUM"  field.  If  the  new  report 
pertained  to  the  AVCS,  then  "AVCS"  should  be  entered  in  the 
"SUBSYS"  field.  If  the  report  pertained  to  a  Loss  of  Earth 
problem  that  occurred  under  normal  operating  conditions,  then 
enter  "1"  in  the  "UNKCOND"  field  (corresponds  to  "Normal  Ops"  and 


event  =  1),  "5"  in  the  "UNKNORM"  field  (corresponds  to  "Loss  of 
Earth"  subgroup  and  normvent  =  5),  "1"  in  the  AVCSCOND  field  and 
"1"  in  the  AVCSNORM  field.  There  is  no  corresponding  subgroup 
under  the  EPS,  but  the  developer  may  also  want  to  list  this  report 
for  Load  Shed  problems.  In  this  case,  enter  "1"  in  the  "EPSCOND" 
field  (corresponds  to  "Normal  Ops"  and  event  =  1),  and  "1"  in  the 
"EPSNORM"  field  (corresponds  to  "Load  Shed"  subgroup  and  normvent 
9  1).  (The  appropriate  number  to  enter  in  any  of  the  last  six 
fields  can  be  determined  by  examining  the  particular  rule  set's 
menu )  . 

Of  course,  the  same  report  may  be  listed  in  several  records 
if  it  is  relevant  to  multiple  circumstances  or  subgroups.  In  any 
case,  the  developer  must  ensure  that  the  values  entered  In  the 
table  for  "XXXCOND"  and  "XXXNORM"  correspond  to  the  values  of 
event  and  normvent  for  each  subsystem  rule  set. 
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Appendix  B:  User  * s  Guide 


This  user's  guide  is  presented  with  the  assumption  that  the 
Guru  software  has  already  been  loaded  into  the  user's  system  and 
that  a  Guru  directory  has  been  created.  It  is  also  assumed  that 
the  user  has  installed  Guru  on  a  Z-248  or  other  IBM  PC  compatible 
microcomputer  with  the  floppy  disk  drive  labeled  "A"  and  the  hard 
disk  drive  labeled  "C." 

Installation 

There  are  14  files  which  must  be  loaded  onto  the  user’s  hard 
disk  for  NAVARES  execution. 

a 


1. 

unk . rss 

6. 

bat .rss 

11. 

epsdia . ipf 

2. 

avcs . rss 

7. 

yaw. ess 

12. 

bccdia . ipf 

3. 

epsdia .rss 

8. 

gps.ipf 

13. 

batd  La . ipf 

4. 

sa.rss 

9  . 

smallkbs . ipf 

14. 

pr  .  itb 

5. 

Is . rss 

10. 

search. ipf 

There  are  also  three  "batch"  files  of  MSDOS  commands  that  should 
be  useful:  ens.bat,  in. bat,  and  out. bat.  The  maintenance  guide 
in  Appendix  A  provides  a  description  of  each  file. 

To  copy  all  the  necessary  files  onto  the  user’s  system  simply 
execute  the  in. bat  batch  file  by  typing  "in"  at  the  A  drive  prompt 
or  by  copying  the  in. bat  batch  file  into  the  Guru  directory  and 
then  typing  "in"  at  the  "CAGURU"  prompt. 

Once  all  the  necessary  files  have  been  copied  into  the  Guru 
directory,  the  gps.ipf  file  should  be  copied  into  filename 
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"startup. ipf ."  Guru  will  automatically  execute  any  file  named 
"startup. ipf"  when  it  is  initialized.  With  all  the  files 
transferred  and  startup. ipf  created  NAVARES  is  ready  for 
execution. 

Execution 

To  execute  NAVARES  the  user  must  type  "ens"  at  the  C\GURU 
prompt.  This  command  will  initialize  the  Guru  environment  and 
begin  a  NAVARES  session.  The  first  few  screens  provide  ar. 
introduction  to  NAVARES  and  ask  for  the  user's  name,  the  date,  and 
the  SVN .  When  NAVARES  prompts  the  user  for  information,  whether 
it  be  "Y"  or  "N" ,  or  the  user's  name,  the  information  should  be 
typed  at  the  keyboard  and  entered  by  pressing  the  "Return''  key. 

The  first  point  where  the  user  must  make  an  important 
decision  is  at  the  menu  which  asks  for  the  anomalous  subsystem 
(see  Figure  9).  Here  the  user  roust  choose  to  ..arrow  the  search 
for  a  solution  or  enter  "Unknown."  Selections  are  made  from  all 
menus  by  pressing  the  number  key  corresponding  to  the  user's 
choice  or  by  using  the  keyboard  arrows  to  highlight  the  user's 
choice  before  pressing  the  "Return"  key. 


Does  this  anomaly  seem  to  be  in  the  AVCS  or  EPS? 

1.  Attitude,  Velocity  and  Control  Subsystem 

2.  Electrical  Power  Subsystem 

3.  Unknown 


Figure  9.  Subsystem  Menu 


78 


For  the  purposes  of  this  discussion,  assume  the  AVCS  is 


selected.  The  next  menu  will  then  prompt  the  user  for  the 
circumstances  under  which  the  anomaly  occurred  (see  Figure  10). 

The  user  does  not  have  the  option  of  answering  "Unknown"  in  this 
case. 

What  were  the  circumstances  of  the  anomalous  event? 

1.  Normal  Operations 

2.  Delta-V  maneuver 

3.  Spin  stabilization 

4.  DMMD  execution 

Figure  10.  Circumstances  Menu 
Assuming  that  "Normal  Operations"  was  selected,  the  user  is 
then  asked  to  narrow  the  problem  to  a  particular  subgroup  (see 
Figure  11).  For  this  example  assume  "Loss  of  Earth"  is  selected. 
Of  course,  determining  the  subgroup  may  not  be  possible  or  prudent 
so  the  user  may  select  "Unknown." 


Please  narrow  the  problem  to  one  of  the  following 
categories . 

1.  Loss  of  Earth 

2.  Magnet  related 

3.  Reaction  Wheel  related 

4.  Momentum  dump  related 

5.  Yaw  related 

6.  Unknown 

Figure  11.  Subgroup  Menu 
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*■ 

Once  the  subgroup  is  selected,  the  u~er  will  then  be 
presented  a  series  of  questions  to  help  NAVARES  reach  a  solution. 
Figure  12  shows  the  sequence  of  questions  and  the  answers 
(underlined)  given  by  the  user  in  this  example.  (The  user  should 
note  the  comment  "Thinking...  please  wait"  in  the  lower  left  of 
the  screen  after  each  answer  is  entered.  Do  not  make  any  entries 
while  this  message  is  displayed.) 


Are  the  pitch  and  roll  error  less  than  or  equal  to 
2  degrees?  (Y/N)  N 
(new  screen) 

Is  the  pitch  and  roll  override  enabled?  (Y/N)  N. 
(new  screen) 

The  SV  has  experienced  loss  of  earth. 


1*  .*  •  ^  n  li  AM  1  <4  K  A  m  _ 

pu  autctupu  onuuiw  */v  mm 


A  A  f  Q  annAcg  fKc  C  V  Until  j.  t  X  S 


saf ed . 

Press  any  key  to  continue, 

(new  screen) 

Has  Load  Shed  2  occurred?  (Y/N)  Y 
(new  screen) 

Is  the  solar  panel  gimbal  angle  appropriate  for  the  position 
in  the  SV's  orbit  where  Load  Shed  2  occurred?  (Y/N)  N 


Figure  12.  Sample  Query  Sequence 


This  particular  sequence  of  questions  leads  to  a  solution 
which  is  displayed  after  the  last  question  is  answered.  The  user 
is  then  presented  with  a  block  diagram  of  the  EPS  indicating  the 
anomalous  component.  The  visual  indication  is  only  available  for 
three  demonstration  cases:  the  case  described  here,  the  case  or 
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excessive  discharge  during  battery  reconditioning,  and  the  case  of 
a  probable  battery  failure.  The  next  screen  displayed  allows  the 
user  to  view  and  print  the  desired  output. 

Output 

Figure  13  shows  the  final  menu.  From  this  point  the  user  can 
view  the  final  report  and  results  of  the  past  anomaly  report 
search,  print  this  information,  and  exit.  If  "Display  Report"  is 
selected,  the  final  report  is  displayed  and  at  the  bottom  of  the 
screen  a  message  appears  asking  the  user  if  he  would  like  to  view 
the  results  of  the  past  report  search.  Typing  "N"  will  return  the 
user  to  the  final  menu.  Typing  "Y"  will  cause  NAVARES  to  present 
the  results  of  the  search  before  returning  the  user  to  the  final 
menu.  From  iiezc,  the  user  may  choose  to  print  the  report  and 
search  results  or  simply  exit. 


1. 

Display  Report 

2. 

Print  Report 

3. 

Exit 

Figure  13.  Final  Menu 


Menu  Selections 

The  user  should  be  aware  that  it  is  possible  to  reach  the 
same  solution  following  different  paths.  For  example,  the 
solution  described  above  could  have  been  reached  by  selecting  AVCS 
from  the  subsystem  menu  and  "Unknown"  from  the  subgroup  menu.  In 


addition,  the  user  could  have  selected  "Unknown"  from  the 
subsystem  menu  and  "Loss  of  Earth"  or  "Unknown"  from  the  subgroup 
menu  to  reach  the  same  solution. 

There  is  a  trade-off  between  narrowing  the  problem 
immediately  and  choosing  "Unknown"  from  the  menus.  Narrowing  the 
problem  will  decrease  the  number  of  questions  asked  of  the  user 
and  speed  execution  time.  However,  narrowing  the  problem  may  also 
deprive  the  user  of  the  correct  solution  since  NAVARES  will  ignore 
possible  solutions  outside  of  the  specified  subsystem  and 
subgroup . 

Summary 

This  user’s  guide  provides  a  brief  introduction  to  NAVARES 
execution.  The  maintenance  guide  contains  more  detailed 
information  on  files  and  their  functions,  key  variables,  and  data 
table  updates.  The  System  Design  and  Implementation  chapter  also 
provides  further  explanation  for  the  interested  user. 
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